commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
Subject Re: [PROPOSAL] Commons Runtime API for Persistence
Date Sat, 02 Apr 2005 05:40:09 GMT
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


Mime
View raw message