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 Sat, 02 Apr 2005 04:57:04 GMT
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


Mime
View raw message