James, I understand your point, but I think my idea fits within both the letter and spirit of Geir's proposal:
> ... we think that commons persisting should just enhance the > mystery and intrigue of adding apparently innocuous dependencies > to a project. Whenever you translate from A -> B -> A you have lots of opportunities to introduce subtle and not so subtle semantic differences, thus adding to the mystery and intrigue. > create a single API, to be known as "Commons Persisting" which allows > isolation from the fashions and trends in persisting technology. As the user only sees JDBC, they are totally isolated from the fashions, trends, and benefits of the various persistence mechanisms. > This API will not : > > - define a query language similar to any other My proposal doesn't define a query language at all, it uses SQL. > - define a query language conforming to standard set thEory SQL doesn't conform to set theory (and Chris Date sure has a lot to say about NULL) > - define an O/R mapping metadata syntax Not needed. > - define rules for object lifecycle with respect to the methods in > this API Not needed. > - use <insert favorite unproven technology here> Ditto. > - constrain the types of objects and object models that a given > plug-in > might support I think we're ok on this one. > - keep Hani quiet No clue about this. > > This API will : > > - allow users to use one set of simple interfaces for persisting > objects Yes, the JDBC interfaces. > - allow different providers to be "plugged-in" Yes, we can plug in any persistence technology we write an adapter for. > - define an API for execution of queries Well, we reuse one... > - piss off various and sundry expert group members > Actually, his original proposal as it stands didn't generate much controversy here, so I think my elaboration has helped in this regard. One issue Geir didn't bring up, but I think I have covered is that the user need not have any direct dependence on the Commons Runtime API for Persistence. We can configure it externally and use either lookup or injection to allow the application to gain a reference to our DataSource. Doing so avoids the need for the code to contain: import org.apache.commons.crap.* which otherwise would obviously lead to code smells. Finally, my comments about timezones and Martin's and Phil's followups are directly related to: http://en.wikipedia.org/wiki/April_Fool%27s_Day#Present_day Hope this helps, Jim --- James Carman <[EMAIL PROTECTED]> wrote: > Maybe I'm a bit dense here, but I really don't understand what you're > saying. Why would someone want to use the JDBC API to write their > persistence code? That's why we came up with O/R mapping solutions > in the > first place! Writing your persistence layer yourself using JDBC is > buggy at > best and quite cumbersome, no matter what driver you use behind the > scenes. > A real "object-based" persistence API would allow you to treat a data > source > (RDBMS, OODBMS, LDAP, XML files, etc.) as simply "something that > allows me > to store and retrieve objects." The JDBC API doesn't provide that. > It's > targeted for a purely RDBMS/SQL environment. I'm with Henri here in > that I > don't understand how the JDBC API gets involved here at the level > we're > talking about. Of course most implementations of the Commons > Persisting API > would use JDBC behind the scenes, but let's let those experts (like > the > Hibernate and JDO folks) worry about how all of that is done and > we'll just > concentrate on storing and retrieving objects. > > The only problem I have with this proposal is that we may run into > the same > gripes that folks have with the Commons Logging API, how it is > limited by > the fact that it has to be the "least common denominator." I like > the idea, > though. It would be cool to be able to swap in another vendor's > persistence > implementation and not have to change one line of my code. I'd have > to say > that I'd be a +1 overall. > > > > -----Original Message----- > From: Jim Seach [mailto:[EMAIL PROTECTED] > Sent: Sunday, April 03, 2005 1:59 PM > To: Jakarta Commons Developers List; Henri Yandell > Subject: Re: [PROPOSAL] Commons Runtime API for Persistence > > > 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] > > > > --------------------------------------------------------------------- > 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]
