[web-devel] Database.Persistent

[Felipe Almeida Lessa]

On Fri, May 6, 2011 at 12:31 AM, Greg Weber <greg at gregweber.info> wrote:
> 1) lazy IO, but don't hold a connection open- accessing a lazy field creates
> an entirely new request. This means a change in the type signature of the
> field accessor to be in IO.

I think lazy IO is out of question.  But I don't get this change in
the type signature.

> 2) A to be excluded field must be nullable, and excluding it will return a
> Nothing. Instead of a runtime failure, you get a runtime wtf? moment if you
> don't realize why your data is not being displayed.

How would you find out if it is Nothing because you didn't ask for it,
or if it's Nothing because it really is Nothing?  There must be
something to tell one situation from the other.  So I guess this is
not acceptable as well.

But a similar approach may be acceptable:

  Person
    name String
    photo ByteString

would become

  data Person = Person {name :: String, photo :: ByteString}

But then you could say

  Person
    name String
    photo ByteString Large

and then it would become

  data Person = Person {name :: String, photo :: Fetched ByteString}

where

  data Fetched a = NotFetched | Fetched !a

The good:
 - No combinatorial explosion.
 - No undefined values.

The bad:
 - Can't statically check that everything was fetched, for example,
when inserting.

Some variants:

a) Two data types

  data Person = Person {name :: String, photo :: ByteString}
  data PersonOpt = PersonOpt {nameOpt :: String, photoOpt :: Fetched ByteString}

b) GADTs

  data Person t = Person {name :: String, photo :: Fetched t ByteString}

  data Fetched t a where
    NotFetched :: Fetched Incomplete a
    Fetched :: a -> Fetched Complete a

  data Incomplete
  data Complete

Note that all names are terrible =(, but that's another bikeshed ;).

Cheers,

-- 
Felipe.