
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
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
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
wrote: On Thu, May 5, 2011 at 1:28 PM, Felipe Almeida Lessa
wrote: On Thu, May 5, 2011 at 2:20 AM, Jeremy Hughes
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@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel