[web-devel] Database.Persistent

[Michael Snoyman]

It looks to me like a combination of options 2 and 3 below.

On Fri, May 6, 2011 at 1:07 PM, Aristid Breitkreuz
<aristidb at googlemail.com> wrote:
> What about
>
> data Foo = X { a :: Int }
> data FooLifted = XLifted { aLifted :: Maybe Int }
>
> As I indicated earlier. Sorry for not being more eloquent on my phone.
>
> Aristid
>
> Am 06.05.2011 11:48 schrieb "Michael Snoyman" <michael at snoyman.com>:
>> 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
>>>
>