On Sun, Mar 13, 2011 at 11:42 PM, Greg Weber
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