[web-devel] Sql join feature in persistent

[Антон Чешков]

Michael look at this
http://www-db.informatik.uni-tuebingen.de/files/publications/ferryhaskell.pdf
<http://www-db.informatik.uni-tuebingen.de/files/publications/ferryhaskell.pdf>Very
tempting.

2011/2/22 Michael Snoyman <michael at snoyman.com>

> Max: Let's address your desire for sharding in a separate thread: I
> think it's a good idea, and it's a feature I would like to implement.
> I also think that your approach seems fairly feasible and not too
> disruptive. I want to make sure that introducing sharding code doesn't
> negatively affect users not taking advantage of it.
>
> As for joins (and other relational features): we should definitely add
> some helpers to Persistent. The main questions are:
>
> * What should their type signatures be?
> * Should we offer optimizations for the SQL backends to use proper JOINs?
>
> For the first, I think we still need to clarify a bit. Anton's code is
> a good start, but it certainly won't be amenable to SQL-backend
> optimizations. And I think we *should* strive to produce some
> efficient SQL code, though I want to avoid pouring too much effort
> into such an endeavor. Perhaps if we can write some code to handle the
> most common cases (eg, a 1-to-many relation between two tables) we'll
> be adhering well to the 80/80 rule.
>
> My ideal would be having some nice high-level functions that handle
> joins, optimize those to proper SQL joins where possible, and for
> backends where that is not possible simply do the join logic in
> Haskell.
>
> I definitely won't have time to get started on this coding for the
> next few weeks, but if anyone is interested in trying to implement any
> of the features under discussion, let me know, and I'll be happy to
> offer any assistance/code review I can.
>
> Michael
>
> On Tue, Feb 22, 2011 at 4:39 PM, Greg Weber <greg at gregweber.info> wrote:
> > The basic Persistent backend is designed without joins ("web-scale"), and
> > with the idea that it should be SQL agnostic. App-level join
> functionality
> > is definitely needed.
> > If someone wanted to design a layer on top of it with other SQL features
> > that just the SQL backends can use that is fine. However, this might
> start
> > re-inventing the wheel. For those interested in SQL joins and otherwise
> > advanced SQL queries, it would be great if they started trying out a
> better
> > tool for the job, like the recently released DSH [1] or (bitrotting?)
> > HaskellDB. Relational Algebra sql query libraries can be very productive
> to
> > use for 95% of use cases, even if they aren't "web-scale".
> > [1] http://hackage.haskell.org/package/DSH
> > [2] http://hackage.haskell.org/package/TableAlgebra
> > _______________________________________________
> > 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
>



-- 
Best regards,
Cheshkov Anton
Phone: +7 909 005 18 82
Phone: +7 931 511 47 37
Skype: cheshkov_anton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20110222/bccb8a8b/attachment.htm>