commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Seach <jwse...@yahoo.com>
Subject RE: [PROPOSAL] Commons Runtime API for Persistence
Date Mon, 04 Apr 2005 01:42:42 GMT
Well, It looked pretty good to me on first read too, but I wasn't sure
how we would approach it.  On re-reading it, the light bulb came on,
and I wrote my "proposal".

Looks like you skimmed it, liked it, and started coming up with
implementation options!  Nothing wrong with that.


--- James Carman <james@carmanconsulting.com> wrote:

> Jim,
> 
> Ahhhhh.  An April Fools joke (light bulb finally comes on).  Well, I
> guess
> the joke's on me.  Guess I should check my calendar every now and
> then.  I
> told you I was a bit dense!  :-)  I do like the acronym, though.  Can
> we
> still do something that will "piss off various and sundry expert
> group
> members"?  That's what sold me! ;-)
> 
> James
> 
> -----Original Message-----
> From: Jim Seach [mailto:jwseach@yahoo.com] 
> Sent: Sunday, April 03, 2005 8:21 PM
> To: Jakarta Commons Developers List
> Subject: RE: [PROPOSAL] Commons Runtime API for Persistence
> 
> 
> James,
> 
> You are, of course, correct and make a lot of good points.  My
> proposal just
> adds complexity and doesn't buy you anything over what we get with
> JDBC.
> 
> I may have completely misread Geir's proposal, but did you look at
> the
> acronym?  Also, take a look at the link at the end of my last
> message. 
> I think this is the spirit in which he made the proposal. ;^)
> 
> In my view, the Commons Runtime API for Persistence (CRAP) is not
> really
> necessary.  If you use good application design, it should be
> relatively easy
> to move from one tool to another.  Also, given the rate of innovation
> currently happening in this area, it would be premature to try to
> abstract
> out a lowest common denominator.
> 
> I just took Geir's proposal and ran with it in the direction I think
> he
> started.  :^)
> 
> Thanks,
> 
> Jim
> 
> --- James Carman <james@carmanconsulting.com> wrote:
> 
> > Jim,
> > 
> > How about this?  Why don't you put up some sample code so that we
> can 
> > see what you envision.  At this point, I don't get it.  If the JDBC
> 
> > API was
> > sufficient in the first place, we wouldn't have ever needed O/R
> > mapping
> > technologies to abstract our data sources.  Persistence
> technologies
> > such as
> > Hibernate or JDO have many features which JDBC doesn't support in
> and
> > of
> > itself.  For example, how do I tell a JDBC connection (or
> statement)
> > to
> > delete an object?  There is no delete( Object o ) method in the
> JDBC
> > API.
> > Also, if I want to add an object to the persistence store, I can
> just
> > do
> > save( Object o ) or something similar, but not with JDBC.  I have
> to
> > construct an insert statement and map the properties in my object
> to
> > columns
> > in the database table (assuming our mapping is just that simple). 
> > Maybe a
> > code sample would help me/us (I'm assuming others are having
> trouble
> > with
> > this, but it could just be me).  How about this.  Consider the
> > following
> > class...
> > 
> > public class Person
> > {
> >   private String firstName;
> >   private String lastName;
> >   private int ssn;
> > 
> >   // Setters/Getters
> > }
> > 
> > Now, using the JDBC API (let's assume Commons Persisting is our 
> > driver), how would you...
> > 
> > 1.  Create a Person object in the data store.
> > 2.  Retrieve a Person object from the data store.
> > 3.  Update a Person object in the data store.
> > 4.  Delete a Person object from the data store.
> > 
> > These are the fundamental CRUD operations that any O/R mapping
> system 
> > needs to support.  I'm not saying that it can't be done using JDBC 
> > (there are many
> > existing examples to refute that claim).  I'm just saying that it's
> > MUCH
> > more difficult with JDBC than with Hibernate or JDO, for instance. 
> 
> > 
> > James
> > 
> > -----Original Message-----
> > From: Jim Seach [mailto:jwseach@yahoo.com]
> > Sent: Sunday, April 03, 2005 4:47 PM
> > To: Jakarta Commons Developers List
> > Subject: RE: [PROPOSAL] Commons Runtime API for Persistence
> > 
> > 
> > James,
> > 
> > I understand your point, but I think my idea fits within both the 
> > letter and spirit of Geir's proposal:
> > 
> > > ... we think that commons persisting should just enhance the
> > mystery
> > > and intrigue of adding apparently innocuous dependencies to a
> > project.
> > 
> > Whenever you translate from A -> B -> A you have lots of
> opportunities 
> > to introduce subtle and not so subtle semantic differences, thus 
> > adding to the
> > mystery and intrigue.
> > 
> > > create a single API, to be known as "Commons Persisting" which
> > allows
> > > isolation from the fashions and trends in persisting technology.
> > 
> > As the user only sees JDBC, they are totally isolated from the 
> > fashions, trends, and benefits of the various persistence
> mechanisms.
> > 
> > > This API will not :
> > > 
> > > - define a query language similar to any other
> > 
> > My proposal doesn't define a query language at all, it uses SQL.
> > 
> > > - define a query language conforming to standard set thEory
> > 
> > SQL doesn't conform to set theory (and Chris Date sure has a lot to
> 
> > say about NULL)
> > 
> > > - define an O/R mapping metadata syntax
> > 
> > Not needed.
> > 
> > > - define rules for object lifecycle with respect to the methods
> in
> > > this API
> > 
> > Not needed.
> > 
> > > - use <insert favorite unproven technology here>
> > 
> > Ditto.
> > 
> > > - constrain the types of objects and object models that a given
> > > plug-in might support
> > 
> > I think we're ok on this one.
> > 
> > > - keep Hani quiet
> > 
> > No clue about this.
> > 
> > > 
> > > This API will :
> > > 
> > > - allow users to use one set of simple interfaces for persisting
> > > objects
> > 
> > Yes, the JDBC interfaces.
> > 
> > > - allow different providers to be "plugged-in"
> > 
> > Yes, we can plug in any persistence technology we write an adapter 
> > for.
> > 
> > > - define an API for execution of queries
> > 
> > Well, we reuse one...
> > 
> > > - piss off various and sundry expert group members
> > > 
> > 
> > Actually, his original proposal as it stands didn't generate much 
> > controversy here, so I think my elaboration has helped in this
> regard.
> > 
> > One issue Geir didn't bring up, but I think I have covered is that
> the 
> > user need not have any direct dependence on the Commons Runtime API
> 
> > for Persistence.  We can configure it externally and use either
> lookup 
> > or injection to allow the application to gain a reference to our
> > DataSource.
> > Doing so avoids the need for the code to contain:
> > 
> > import org.apache.commons.crap.*
> > 
> > which otherwise would obviously lead to code smells.
> > 
> > Finally, my comments about timezones and Martin's and Phil's
> followups 
> > are directly related to:
> > 
> > http://en.wikipedia.org/wiki/April_Fool%27s_Day#Present_day
> > 
> > Hope this helps,
> > 
> > Jim
> > 
> > 
> > --- James Carman <james@carmanconsulting.com> wrote:
> > 
> > > Maybe I'm a bit dense here, but I really don't understand what
> > you're
> > > saying.  Why would someone want to use the JDBC API to write
> their
> > > persistence code?  That's why we came up with O/R mapping
> solutions
> > in
> > > the first place!  Writing your persistence layer yourself using
> > JDBC
> > > is buggy at
> > > best and quite cumbersome, no matter what driver you use behind
> the 
> > > scenes. A real "object-based" persistence API would allow you to 
> > > treat a
> > data
> > > source
> > > (RDBMS, OODBMS, LDAP, XML files, etc.) as simply "something that 
> > > allows me to store and retrieve objects."  The JDBC API doesn't 
> > > provide that.
> > 
> > > It's
> > > targeted for a purely RDBMS/SQL environment.  I'm with Henri here
> > in
> > > that I
> > > don't understand how the JDBC API gets involved here at the level
> 
> > > we're talking about.  Of course most implementations of the
> Commons
> > > Persisting API
> > > would use JDBC behind the scenes, but let's let those experts
> (like
> > > the
> > > Hibernate and JDO folks) worry about how all of that is done and
> > > we'll just
> > > concentrate on storing and retrieving objects.  
> > > 
> > > The only problem I have with this proposal is that we may run
> into
> > the
> > > same gripes that folks have with the Commons Logging API, how it
> is 
> > > limited by the fact that it has to be the "least common 
> > > denominator."  I like the idea,
> > > though.  It would be cool to be able to swap in another vendor's
> > > persistence
> > > implementation and not have to change one line of my code.  I'd
> > have
> > > to say
> > > that I'd be a +1 overall.
> > > 
> > > 
> > > 
> > > -----Original Message-----
> > > From: Jim Seach [mailto:jwseach@yahoo.com]
> > > Sent: Sunday, April 03, 2005 1:59 PM
> > > To: Jakarta Commons Developers List; Henri Yandell
> > > Subject: Re: [PROPOSAL] Commons Runtime API for Persistence
> > > 
> > > 
> > > What I was envisioning is that the user would write his object
> > > persistence using the JDBC API, the whole ball of wax, but use
> the 
> > > Commons Persistence
> > > JDBC Driver instead of the one for his target database.
> > > 
> > > The Commons Persistence JDBC Driver would translate all calls to
> > calls
> > > on the chosen persistence API which would be configured in the
> > usual
> > > manner.
> > > 
> > > The chosen persistence API would then make calls on the target
> > > database to realize the desired operations.
> > > 
> > > This would make it easy to unit test without a database: just use
> a
> > 
> > > mock JDBC driver as the target database and verify that all JDBC
> > calls
> > > made by
> > > the application are faithfully transmitted on to the target
> > database.
> > > 
> > > A later version of the api could allow using multiple persistence
> > > frameworks in the same application, with all the concomitant 
> > > advantages of buzzword
> > > compliance and resume padding appertaining thereto.
> > > 
> > > 
> > > --- Henri Yandell <flamefew@gmail.com> wrote:
> > > 
> > > > Can't say I understand how Geir's proposal could be solved with
> 
> > > > anything at the JDBC level, it's just going to seem too weird
> to
> > > try
> > > > and jam a object query into a JDBC class.
> > > > 
> > > > The most I would expect is for debate on whether the API would
> be
> > > able
> > > > to take a java.sql.Connection of javax.sql.DataSource object,
> or
> > if
> > > > it would be left to the underlying Object-Mapping-'driver'.
> > > > 
> > > > +1 to the idea.
> > > > 
> > > > Hen
> > > > 
> > > > On Apr 1, 2005 11:57 PM, James Carman
> > <james@carmanconsulting.com>
> > > > wrote:
> > > > > Do you propose sticking with SQL queries?  Or, do you mean
> use
> > > the
> > > > JDBC
> > > > > framework (Connection, Statement, ResultSet, etc.) to execute
> > > > object-based
> > > > > queries?
> > > > > 
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Jim Seach [mailto:jwseach@yahoo.com]
> > > > > Sent: Friday, April 01, 2005 11:14 PM
> > > > > To: Jakarta Commons Developers List
> > > > > Subject: Re: [PROPOSAL] Commons Runtime API for Persistence
> > > > > 
> > > > > Well, we could take it a step further:
> > > > > 
> > > > > We don't need to invent our own api, just adopt one and write
> > the
> > > > necessary
> > > > > adapters.  I propose using the JDBC api with our own
> > > DriverManager
> > > > and
> > > > > DataSources.  The application or library developer will
> handle
> > > > their
> > > > > persistence needs using the standard JDBC api, and our
> adapters
> > > > will
> > > > > intercept the calls and translate them into calls on the
> > desired
> > > > persistence
> > > > > layer.
> > > > > 
> > > > > Does it matter that your post was sent past Midnight GMT?  It
> > is
> > > > still
> > > > > Friday in both yours and my time zones.
> > > > > 
> > > > > --- "Geir Magnusson Jr." <geirm@apache.org> wrote:
> > > > > >
> > > > > > a.k.a. "Commons Persisting"
> > > > > >
> > > > > > Motivation
> > > > > > ----------
> > > > > > There are an increasing number of viable APIs for
> persisting
> > > > objects
> > > > > > to data stores.  We currently have JDO, a JCP spec,
> > Hibernate,
> > > a
> > > > > > popular
> > > > > >
> > > > > > open source project, OJB, an Apache open source project,
> > EJB3,
> > > a
> > > > new
> > > > > > JCP spec for object persistence,  commercial products such
> as 
> > > > > > Toplink, and many others such as Abra, BasicWebLib, Castor,
> 
> > > > > > Cayenne,
> > > > DataBind,
> > > > > >
> > > > > > DBVisual Architect, EnterpriseObjectsFrameworks, Expresso,
> > > > FireStorm,
> > > > > >
> > > > > > iBATIS, Infobjects, InterSystems Cache, JULP, Jaxor, JDX,
> > Kodo,
> > > > LiDO,
> > > > > >
> > > > > > O/R Broker, Planet J's WOW, intelliBO, SimplOrm, Spadesoft
> > > XJDO,
> > > > > > Sql2Java, PE:J, VBSF and others.
> > > > > >
> > > > > > Each of these solutions have strengths and weaknesses and
> are
> > > > chosen
> > > > > > by developers based on specific project needs, political 
> > > > > > considerations,
> > > > > >
> > > > > > or quality of golf outings provided by the technology
> > > > salesperson.
> > > > > >
> > > > > > Like the situation that developed a few years ago with
> > logging,
> > > > in
> > > > > > which developers were forced to choose between the de-facto
> > > > standard,
> > > > > >
> > > > > > Apache Log4J, or the JCP-defined spec, java.util.logging,
> we
> > > > believe
> > > > > > that we have a similar situation today - developers are
> > forced
> > > to
> > > > > > commit to an API or product for persisting objects which
> may
> > > > limit
> > > > > > usefulness to users who may have a legacy persisting
> > > technology,
> > > > or
> > > > > > choose an different technology than the software was
> > developed
> > > > for.
> > > > > > Further, there is no way to insulate software from "API
> > > lock-in",
> > > > to
> > > > > > allow software to be used with different persisting APIs as
> > > > style,
> > > > > > fads
> > > > > > and technology concerns dictate.  Finally, there is no way
> to
> > > > ensure
> > > > > > that arbitrary dependencies that a project uses can, in an
> > > ad-hoc
> > > > > > way, find and write to the application's data store.  In
> the
> > > same
> > > > > > way
> > > > that
> > > > > >
> > > > > > components using commons-logging never cease to delight and
> > > > surprise
> > > > > > users, we think that commons persisting should just enhance
> > the
> > > 
> > > > > > mystery and intrigue of adding apparently innocuous
> > > dependencies
> > > > > > to a project.
> > > > > >
> > > > > > Proposal
> > > > > > --------
> > > > > >
> > > > > > Following the successful model of "Commons Logging", we
> > propose
> > > > to
> > > > > > create a single API, to be known as "Commons Persisting"
> > which
> > > > allows
> > > > > >
> > > > > > isolation from the fashions and trends in persisting
> > > technology.
> > > > > >
> > > > > > This API will not :
> > > > > >
> > > > > > - define a query language similar to any other
> > > > > > - define a query language conforming to standard set thEory
> > > > > > - define an O/R mapping metadata syntax
> > > > > > - define rules for object lifecycle with respect to the
> > methods
> > > > in
> > > > > > this API
> > > > > > - use <insert favorite unproven technology here>
> > > > > > - constrain the types of objects and object models that a
> > given
> > > 
> > > > > > plug-in might support
> > > > > > - keep Hani quiet
> > > > > >
> > > > > > This API will :
> > > > > >
> > > > > > - allow users to use one set of simple interfaces for
> > > persisting
> > > > > > objects
> > > > > > - allow different providers to be "plugged-in"
> > > > > > - define an API for execution of queries
> > > > > > - piss off various and sundry expert group members
> > > > > >
> > > > > > Comments?
> > > > > >
> > > > > > --
> > > > > > Geir Magnusson Jr                                 
> > > > +1-203-665-6437
> > > > > > geirm@apache.org
> > > > > >
> > > > > >
> > > > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
> > > > commons-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail:
> > > > commons-dev-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > > 
> > > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> > > commons-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> > > > commons-dev-help@jakarta.apache.org
> > > > > 
> > > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> > > commons-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> > > > commons-dev-help@jakarta.apache.org
> > > > > 
> > > > >
> > > > 
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > commons-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > > commons-dev-help@jakarta.apache.org
> > > > 
> > > > 
> > > 
> > > 
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > commons-dev-help@jakarta.apache.org
> > > 
> > > 
> > > 
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > commons-dev-help@jakarta.apache.org
> > > 
> > > 
> > 
> > 
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> > 
> > 
> > 
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 


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


Mime
View raw message