[web-devel] Database.Persistent

[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 <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).
>>> 
>>> Michael
>>> 
>>> _______________________________________________
>>> web-devel mailing list
>>> web-devel at haskell.org
>>> http://www.haskell.org/mailman/listinfo/web-devel
>> 
>> 
> 
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel