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

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