> -----Original Message-----
> From: Eric Dobbs [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 18, 2001 7:33 AM
> To: [EMAIL PROTECTED]
> Subject: Re: query proposals
>
>
>
> 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/[email protected]/msg
> 02469.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.
This sounds cool... on one hand.
On the other - why is it that useful? It might have been cool if you bought
your relational model in one place, got the object model in the other and
then your boss told you that you have to stick them together. Such a tool
would be really helpful. So would be duct tape. But really, how often is
this the case? Unless your really unfortunate, your object model goes hand
in hand with relational model because ultimately they are just different
reflections of the same thing. And all you are buying is that you have to
design and develop them both separately while making sure they are in sync.
>
> 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/[email protected]/msg
> 00347.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.
the subject was something like "Toplink vs. Torque"
>
> 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.
>
I would put it like this: A lot of flexibility for a huge cost with
questionable benefits.
>
> 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.
I think this is more about implementation details and not really the
model...
>
> Ambler's goal is to let the object model be designed
> without being constrained by the mismatch between
> object and relational models.
I see this constraint as natural and I do not see why we should try to get
rid of it...
> 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^).
Exactly.
>
>
> 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
fedor.
-------------------------------
Amicus Plato amicus Aristoteles magis amica veritas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
