[web-devel] [Yesod][Persistent] FooIdEq,FooIdIn

[Aur Saraf]

On Sun, Mar 13, 2011 at 11:42 PM, Greg Weber <greg at gregweber.info> wrote:
> Hi Aur,
> I don't know if you have seen the previous discussions, but it looks like
> you are moving towards creating a SQL relational algebra library. There are
> 2 such existing libraries. The original is haskellDB [1], and the new one is
> DSH [2].

Hi,

I have seen the previous discussions and am very much inspired by them.

Right now I am mainly attempting to add JOIN functionality to
persistent, because I have a large code base that suffers from JOIN
slowness.

I have looked at haskellDB and my conclusion was that there is much
Haskell that I need to learn before I can fully comprehend how it
works.

The only way I could learn this would be by implementing my own toy
version, hence...

> I think this is a very promising direction for Yesod, and I think there is a
> lot to be gained by first looking at one of the existing libraries, and
> seeing if at least the inner core [3] can be used with our constructor
> interface. I think we should at least justify why we are not re-using them.
> Also, I agree that it would be ideal to remove the declaration of which
> actions are used. There are some technical reasons for this, but at a
> minimum they should be justified/documented in the book.
> Greg Weber
> [1] http://hackage.haskell.org/package/haskelldb
> [2] http://hackage.haskell.org/package/DSH
> [3] http://hackage.haskell.org/package/TableAlgebra-0.1.5

> Persistence engine (especially non relational) have a little relevance to web
> development. I would hate to see precious resources being spent on it, rather
> than on what is actually important in web development. Just like happs
> community did for a long time, neglecting documentation and important features
> of web framework itself and concentrating on something that would be in best
> case used by 0.1% of all intrested in the web framework.

Persistent is not its own persistence engine, but a wrapper layer
above SQL/non-relational DBs.

I am improving it to scratch an itch, not because I think it is more
important to the future of Yesod than anything else.

There was some discussion last week about adding JOIN support here on
the list, and as I saw that nobody began to write code - and despite
not having the chops to write it myself, I really need it - I should
begin myself and see if anyone joins me.


> While it's true that it lowers the number of constructors created at
> compile time, that was *not* my primary concern. The idea was to allow
> for optimizations: for a SQL backend, the SQL migration code could
> produce indices automatically. For other backends, it could have an
> even more dramatic effect on how the data is stored.

Sounds like a strong argument for making it a parameter of the FieldType.



Right now I'm having lots of trouble with the TH code generation. I'll
post my code once the first unit tests pass - a lot before it would
actually be useful - to see what you guys say about my methods. Also,
there's a lot of cleaning up - or at least restyling, but I like to
think it is cleaning up - of TH.hs, which is useful in general.

Good night,
  Aur