[web-devel] Database.Persistent

[Michael Snoyman]

So a quick review: we have a few general approaches here:

1) Create a few different datatypes, or a single datatype with
multiple constructors.
2) Somehow annotate the fields to indicate that data may or may not be present.
3) Fill in some dummy values for fields not loaded.

I think option (1) is by far the most type safe. It's also the most
involved and unintuitive. Greg's point about multiple constructors
being ugly is very true. And two datatypes will be hard to manage.

Option (2) will work, but it's significantly less type safe. There's
nothing at the type level distinguishing "get" and "getPartial". And
it will have a strongly negative impact on all code branches using
"get".

Option (3) is not as type-safe as option (1). In it's scariest form,
it's going to allow undefined to float around programs wreaking havoc.
In its more benign form, it will simply allow the user to provide
dummy values. The downside versus option (1) is that there's nothing
at the type level distinguishing get from getPartial. The downside
versus option (2) is that there is nothing at the value level
distinguishing get from getPartial.

But the advantage of (3) is that it's much simpler to implement and
will have no effect on regular code at all. I think it's also much
easier to understand how to use it to someone.

Anyone see something I'm missing?

Michael

On Fri, May 6, 2011 at 7:49 AM, Aristid Breitkreuz
<aristidb at googlemail.com> wrote:
> 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..
>>
>> 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
>>
>>
>> _______________________________________________
>> web-devel mailing list
>> web-devel at haskell.org
>> http://www.haskell.org/mailman/listinfo/web-devel
>