Hello Michael and everyone, I think that it is very repetitive to need to specify what actions can or cannot be done on every field. I think it would better be made part of the FieldType, at least letting you specify defaults that can be edited in the field specification. Also, I definitely see a need for FooIdEq as I'm toying with adding support for more complicated SQL right now. What I have working in a toy hacked environment:

showQuery $ do selectAll (undefined :: Pet) -- hopefully I'll make it possible to select specific fields where_ PetTypeEq Dog -- eventually I'll probably get "PetType .== Dog" to work where_ PetOwner PersonAgeLt 12 "SELECT * FROM Pet WHERE Pet.type=? AND Person.age

I'm currently modifying the TH to support generating

persistFilterToJoins :: Filter val -> [(SomePersistEntity, SomePersistEntity)]

That I need in order to do this in more than a toy environment. When there'll be something half worth showing, I'll upload to git and invite everyone to help (since this is mostly over-my-head Haskell... I've been learning a lot from it). On Sat, Mar 12, 2011 at 8:46 PM, Michael Snoyman wrote:

On Sat, Mar 12, 2011 at 3:07 AM, Katsutoshi Itoh wrote:

...

Hi

I had often wanted FooIdIn, FooIdEq on Foo Persistent type. Would you support this by default?

from japan.

As Max said, glad to see that you're safe.

For FooIdEq: I don't think there is any need, since it can be expressed more succinctly with the "get" function. As for FooIdIn: this *was* a recently requested feature. Maybe we can get it in for the next release. I think it would make sense to add the In attribute to the entity itself, eg:

mkPersist [$persist| Person In    name String    age Int |]

Any objections?

Michael

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

I would like to warn yesod community not to repeat the mistake of happs/happstack framework. 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. Not all of us create next Google or Facebook. Most web development is just putting a web face to existing (often legacy) database application. It's intresting that outside of haskell community among hundreds of web frameworks on all possible languages you practically never see a web framework that bundles a custom persistence engine. At most they provide components that work well with existing relational (and recently nosql) databases. There are important parts of yesod that are still underdeveloped/underdocumented, like subsites, widgets, often needed components like dynamically loaded, sortable, filtered, editable grids, autopopulated dropdowns. Even the formlets library as far as i can understand will be going through a major rewrite. I would suggest moving all activity on persistent engine into a separate project, in order to free development resources for yesod itself. On Sunday, March 13, 2011 02:42:00 PM you 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]. 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

On Sun, Mar 13, 2011 at 1:48 PM, Aur Saraf wrote:

...

Hello Michael and everyone,

I think that it is very repetitive to need to specify what actions can or cannot be done on every field.

I think it would better be made part of the FieldType, at least letting you specify defaults that can be edited in the field specification.

Also, I definitely see a need for FooIdEq as I'm toying with adding support for more complicated SQL right now.

What I have working in a toy hacked environment:

...

showQuery $ do

selectAll (undefined :: Pet) -- hopefully I'll make it possible

to select specific fields

...

where_ PetTypeEq Dog -- eventually I'll probably get

"PetType .== Dog" to work

...

where_ PetOwner PersonAgeLt 12

"SELECT * FROM Pet WHERE Pet.type=? AND Person.age

I'm currently modifying the TH to support generating

...

persistFilterToJoins :: Filter val -> [(SomePersistEntity,

SomePersistEntity)]

That I need in order to do this in more than a toy environment.

When there'll be something half worth showing, I'll upload to git and invite everyone to help (since this is mostly over-my-head Haskell... I've been learning a lot from it).

On Sat, Mar 12, 2011 at 8:46 PM, Michael Snoyman

wrote:

...

On Sat, Mar 12, 2011 at 3:07 AM, Katsutoshi Itoh

wrote:

...

...

Hi

I had often wanted FooIdIn, FooIdEq on Foo Persistent type. Would you support this by default?

from japan.

As Max said, glad to see that you're safe.

For FooIdEq: I don't think there is any need, since it can be expressed more succinctly with the "get" function. As for FooIdIn: this *was* a recently requested feature. Maybe we can get it in for the next release. I think it would make sense to add the In attribute to the entity itself, eg:

mkPersist [$persist| Person In

name String age Int | |]

Any objections?

Michael

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

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

Great effort! That is a mammoth patch. Could you use git add -p to create 2 commits- one with as much of the refactoring as possible, and the other focusing on the additions? Greg Weber On Sun, Mar 20, 2011 at 7:02 PM, Aur Saraf wrote:

On Tue, Mar 15, 2011 at 2:45 AM, Aur Saraf wrote:

...

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.

At last, my first unit test passes. I have something to show.

_join = do a <- insert $ Person "Aur" 12 Nothing b <- insert $ Person "Bar" 13 $ Just "Blue" c <- insert $ Pet a "Mazal" Cat d <- insert $ Pet b "Sasha" Dog pets <- selectList [PetOwner $ PersonNameEq "Hanners"] [] 0 0 assertEmpty pets pets <- selectList [PetOwner $ PersonNameEq "Aur"] [] 0 0 assertNotEmpty pets return ()

"BEGIN" "INSERT INTO \"Person\"(\"name\",\"age\",\"color\") VALUES(?,?,?)" "SELECT last_insert_rowid()" "INSERT INTO \"Person\"(\"name\",\"age\",\"color\") VALUES(?,?,?)" "SELECT last_insert_rowid()" "INSERT INTO \"Pet\"(\"owner\",\"nick\",\"type\") VALUES(?,?,?)" "SELECT last_insert_rowid()" "INSERT INTO \"Pet\"(\"owner\",\"nick\",\"type\") VALUES(?,?,?)" "SELECT last_insert_rowid()" "SELECT \"Pet\".\"id\",\"Pet\".\"owner\",\"Pet\".\"nick\",\"Pet\".\"type\" FROM \"Pet\" INNER JOIN \"Person\" ON \"Person\".\"id\"=\"Pet\".\"owner\" WHERE \"Person\".\"name\"=?" "SELECT \"Pet\".\"id\",\"Pet\".\"owner\",\"Pet\".\"nick\",\"Pet\".\"type\" FROM \"Pet\" INNER JOIN \"Person\" ON \"Person\".\"id\"=\"Pet\".\"owner\" WHERE \"Person\".\"name\"=?" "COMMIT" "INSERT INTO \"Person\"(\"name\",\"age\",\"color\") VALUES(?,?,?) RETURNING id" "INSERT INTO \"Person\"(\"name\",\"age\",\"color\") VALUES(?,?,?) RETURNING id" "INSERT INTO \"Pet\"(\"owner\",\"nick\",\"type\") VALUES(?,?,?) RETURNING id" "INSERT INTO \"Pet\"(\"owner\",\"nick\",\"type\") VALUES(?,?,?) RETURNING id" "SELECT \"Pet\".\"id\",\"Pet\".\"owner\",\"Pet\".\"nick\",\"Pet\".\"type\" FROM \"Pet\" INNER JOIN \"Person\" ON \"Person\".\"id\"=\"Pet\".\"owner\" WHERE \"Person\".\"name\"=?" "SELECT \"Pet\".\"id\",\"Pet\".\"owner\",\"Pet\".\"nick\",\"Pet\".\"type\" FROM \"Pet\" INNER JOIN \"Person\" ON \"Person\".\"id\"=\"Pet\".\"owner\" WHERE \"Person\".\"name\"=?" "BEGIN" "DELETE FROM \"Pet\"" "DELETE FROM \"Person\"" "COMMIT" "DELETE FROM \"Pet\"" "DELETE FROM \"Person\""

join: [OK]

The code is sketchier than an etch-a-sketch-sketch. But it is a place to start playing from.

It can be found at https://github.com/SonOfLilit/persistent, in the branch template-haskell-refactoring. It is a fork from kaoskorobase/persistent, to enjoy the work he did on separating the TH to a separate package.

I'll say again: This is very experimental code, it doesn't work in all - or most - cases, but it shows the way, or at least one way. It can probably be made to work reasonably well with little work. I'll be very happy for any comments or patches cleaning up my code, since this is the most advanced Haskell that I've had the opportunity to write and many a time I found myself working by guessing or by brute force.

Also, Michael, you might want to port some refactoring that I did to the TH code that in my opinion makes it easier to work with, although I am sure I over-did it, so apply some thought to it before taking everything.

Somehow it happened that this whole thing is one huge commit. I wanted it to compile before I commited, and the test needed a lot of new features to compile, and it kinda dragged away into days of work without commiting... Kids, don't do this at home. I shouldn't have.

I'll be very glad for some code review, I feel it is long due. I'm in deeper water than I know how to navigate.

-- Aur