commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <>
Subject Re: [PROPOSAL] Commons Runtime API for Persistence
Date Sat, 02 Apr 2005 02:24:59 GMT
I for one like the idea, except for one thing... I've always been a bit 
turned off by the persistence solutions that have their own query 
language, such as Hibernate.  For me, any solution that didn't work with 
regular standard SQL wouldn't be optimal.  I believe that if the table 
names in a typical SQL query simply refer to objects in the persistence 
solution, it would work (I know it's not *quite( as simple as that, but 
that's the underlying thought).

Otherwise, I'm all for it!

Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies

Geir Magnusson Jr. 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?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message