iand675 at gmail.com
Fri May 6 04:35:43 CEST 2011
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..
> 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
> >> no support for this directly in persistent, but it might be possible to
> >> 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
> >> 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
> >> dummy error fields.
> >> Greg Weber
> >> On Thu, May 5, 2011 at 4:18 AM, Michael Snoyman <michael at snoyman.com>
> >>> 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>
> >>>>> Is Database.Persistent lazy wrt reading fields? I need to iterate
> >>>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the web-devel