Am 06.05.2011 04:03 schrieb "Max Cantor" <mxcantor@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..
>
> 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@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@snoyman.com> wrote:
>>>>
>>>> On Thu, May 5, 2011 at 1:28 PM, Felipe Almeida Lessa
>>>> <felipe.lessa@gmail.com> wrote:
>>>>> On Thu, May 5, 2011 at 2:20 AM, Jeremy Hughes <jedahu@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@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