mxcantor at gmail.com
Fri May 6 04:02:12 CEST 2011
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
> We may consider requiring the user to supply the value instead,
> thereby avoiding the library inserting undefined.
> 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).
>>> web-devel mailing list
>>> web-devel at haskell.org
> web-devel mailing list
> web-devel at haskell.org
More information about the web-devel