commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject RE: [PROPOSAL] Commons Runtime API for Persistence
Date Sun, 03 Apr 2005 20:15:26 GMT
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


Mime
View raw message