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]
