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@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..

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