[web-devel] Database.Persistent

[Ian Duncan]

Not sure that I feel *quite* so strongly about it as Max, but I agree with
his sentiments here. I'm not convinced that a proper implementation that
could deal with undefineds would be particularly error-prone, but I imagine
that performance would be better anyways with TH.

On Thu, May 5, 2011 at 9:02 PM, Max Cantor <mxcantor at gmail.com> wrote:

> Personally, I vote against this.  Putting in undefineds maintains
> type-safety.  However, in my mind the primary purpose of static type-safety
> is the avoidance of runtime errors.  This only encourages that.  Perhaps a
> better approach is to have some a TH function to generate "subselects" which
> would be records that only contain the requested data.  Its a bit more
> constraining, but I fear that the alternative is tantamount to curing the
> disease by killing the patient.
>
> furthermore, I worry that allowing undefined's here will start a slippery,
> runtime-error-laden slope which we're better off avoiding..
>
> max
>
>
>
> On May 5, 2011, at 9:55 PM, Michael Snoyman wrote:
>
> > That's interesting: I'd never considered the idea of inserting
> > undefined into fields you want excluded... That could work. The reason
> > I've avoided putting in this (often requested) feature is that I could
> > think of no way to do so and keep type safety. That might be an
> > approach.
> >
> > We may consider requiring the user to supply the value instead,
> > thereby avoiding the library inserting undefined.
> >
> > Michael
> >
> > On Thu, May 5, 2011 at 4:32 PM, Greg Weber <greg at gregweber.info> wrote:
> >> An alternative to laziness would be selecting a subset of fields. There
> is
> >> no support for this directly in persistent, but it might be possible to
> add
> >> it and the future and have the value of an unselected field be something
> >> like undefined.
> >> At the moment you can select sub fields by dropping down to lower-level
> sql
> >> methods (ask Michael about these methods if you are interested). I think
> >> there is a technique for building your persistent data structure back up
> >> from the return of raw sql, which again you might be able to do by
> inserting
> >> dummy error fields.
> >> Greg Weber
> >>
> >> On Thu, May 5, 2011 at 4:18 AM, Michael Snoyman <michael at snoyman.com>
> wrote:
> >>>
> >>> On Thu, May 5, 2011 at 1:28 PM, Felipe Almeida Lessa
> >>> <felipe.lessa at gmail.com> wrote:
> >>>> On Thu, May 5, 2011 at 2:20 AM, Jeremy Hughes <jedahu at gmail.com>
> wrote:
> >>>>> Is Database.Persistent lazy wrt reading fields? I need to iterate
> over
> >>>>> entities containing both small and large fields. I do not need to use
> >>>>> the large fields in this instance, and so would rather they were not
> >>>>> read from the database.
> >>>>
> >>>> IIRC, they are read strictly.  I guess you should put them on a
> >>>> different entity.
> >>>
> >>> That's correct. In fact, Persistent avoids any form of lazy I/O to
> >>> ensure that database connections are returned to the pool as soon as
> >>> possible (amongst other reasons).
> >>>
> >>> Michael
> >>>
> >>> _______________________________________________
> >>> web-devel mailing list
> >>> web-devel at haskell.org
> >>> http://www.haskell.org/mailman/listinfo/web-devel
> >>
> >>
> >
> > _______________________________________________
> > web-devel mailing list
> > web-devel at haskell.org
> > http://www.haskell.org/mailman/listinfo/web-devel
>
>
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20110505/024d1ce8/attachment.htm>