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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > 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:[EMAIL PROTECTED] > > 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." <[EMAIL PROTECTED]> 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 > > > [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
