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, <vagif.verdi@gmail.com> 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.

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 <sonoflilit@gmail.com> 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<? AND
> > Pet.id=Person.id JOIN Person"
> >
> > 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 <michael@snoyman.com>
> >
> > 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