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

Persistent already is a separate project- it is not required for a Yesod app. Perhaps you can try to get others outside Yesod more interested in it? Did you read our roadmap blogpost? We only have a few hours of work officially planned for Persistent. This is open source- those that are actively working on extending Persistent in new directions are scratching their own itch, and we think that is great. It sounds like you have your own Yesod itches to scratch. I couldn't disagree with you more about the importance of a persistent framework. I work with Rails, which people with experience in many of the non-ORM frameworks consider hightly productive. The heart of Rails is its ORM (ActiveRecord), and the conveniences from how they integrated it. In fact, I don't think you could find a popular Ruby web framework that did not bundle an ORM or at least tell you to choose from a list of ORMs. On Sun, Mar 13, 2011 at 3:05 PM, wrote:

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.

...

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

On Sunday, March 13, 2011 02:42:00 PM you wrote: 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 <

cutsea110@gmail.com>

...

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

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