query proposals

[John McNally <jm...@collab.net>]

Could Fedor and Eric give an account on their proposals for a new query
model?

Do either of you consider the code to be usable or nearly usable?  

john mcnally

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: query proposals

[Eric Dobbs <er...@dobbse.net>]

On Thursday, September 13, 2001, at 06:35 PM, John McNally wrote:

> Could Fedor and Eric give an account on their proposals for a new query
> model?
>
> Do either of you consider the code to be usable or nearly usable?

My code is nearly usable.

What I have built is a proof of concept that could be
made to generate any SQL statement you want to throw at
me.  What it's missing is a factory for the SQL
generators, and specific implementations for specific
SQL dialects.  And a complete test suite.

But I think Jason will have some objections to using my
code.  Let me summarize some key points of the discussion.

In this message from the archives, Jason calls for the
next version of Torque to be based on the designs by
Scott Ambler, and to eventually become an implementation
of JDO.

http://www.mail-archive.com/turbine-dev@jakarta.apache.org/msg02469.html

A couple months back I took the time to read two of
Scott Ambler's papers.  They are pdf files and can be
found here:

http://www.ambysoft.com/mappingObjects.html
http://www.ambysoft.com/persistenceLayer.html

Ambler's design for a persistence layer is very well
thought out.  It does on the back end what the MVC
pattern does on the front end.  Where MVC lets the
designers and programmers work independently, Ambler's
design for a persistence layer lets programmers and
DBAs work independently.  Another way to put it...
it allows the database design to vary independently
from the object model.

It would do an excellent job of meeting one of
Fedor's goals:  let the query model be good java code
(as opposed to my goal of making it resemble SQL).
Some of that discussion can be found here:
http://www.mail-archive.com/turbine-dev@jakarta.apache.org/msg00347.html


In contrast, Fedor gave some arguments in an unrelated
thread against what he found in Castor's persistence
layer (which is also modeled on Ambler's design and
also trying to be a JDO implementation).  I can't find
this note in the archives -- Fedor, maybe you can chime
in here.  I remember something about Torque being a
lighter solution that lets the programmer get to work
more easily than the mapping required by Castor.

When I first started working with Turbine (around last
December) I remember some other discussions about the
relative merit of Castor's persistence layer
vs. Torque.  As I recall, the primary complaint about
Castor is that there is a rather complex mapping
required between the object model and the data model.
That's a rather fundamental component of Ambler's
design, and it's exactly what allows the object model
to vary independently from the data model.


What are the goals for the new persistence layer?

My goal was to create something that closely resembled
SQL but with enough abstraction to keep the code
independent of database vendors.  I think my proposal
would be much easier to implement, but it requires
developers to be conversant in SQL -- the method calls
I have created have roughly a one-to-one relationship
with SQL fragments.

Ambler's goal is to let the object model be designed
without being constrained by the mismatch between
object and relational models.  The design is sound, but
it includes the need for mapping between objects and
tables which seemed unpopular in this crowd last
December.  If you care about the persistence layer and
haven't read the two papers I mentioned earlier, I
would suggest you do.  I think you'll find his argument
persuasive.  Even if you aren't persuated, the JDO spec
is heavily influenced by the design, and is a proposed
final draft.  I know that Sun's "standards" don't
necessarily impress this group.  But you can safely
expect to see questions in the future from Sun
worshipers 8^).


So there is still a lot unresolved in the discussion.

I expect that in the long run Scott Ambler's design
will become standard-practice in the industry.  For
this reason I'm mostly in support of Jason's
suggestion.

When last we spoke about this subject, Jason mentioned
having some code in his hands that implements Ambler's
design in Java.  Jason, have you made any progress on
the code from player.sourceforge.net, etc?  It would be
good to hear your impressions.

-Eric

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org