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

[vagif.verdi at gmail.com]

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 at 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 at snoyman.com>
> > 
> > wrote:
> > > On Sat, Mar 12, 2011 at 3:07 AM, Katsutoshi Itoh <cutsea110 at 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 at haskell.org
> > > http://www.haskell.org/mailman/listinfo/web-devel
> > 
> > _______________________________________________
> > web-devel mailing list
> > web-devel at haskell.org
> > http://www.haskell.org/mailman/listinfo/web-devel