aristidb at googlemail.com
Fri May 6 06:49:16 CEST 2011
How about generating a version of the records lifted to Maybe?
Am 06.05.2011 04:03 schrieb "Max Cantor" <mxcantor at gmail.com>:
> 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
>>> 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).
>>>> web-devel mailing list
>>>> web-devel at haskell.org
>> web-devel mailing list
>> web-devel at haskell.org
> web-devel mailing list
> web-devel at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the web-devel