Jim, Ahhhhh. An April Fools joke (light bulb finally comes on). Well, I guess the joke's on me. Guess I should check my calendar every now and then. I told you I was a bit dense! :-) I do like the acronym, though. Can we still do something that will "piss off various and sundry expert group members"? That's what sold me! ;-)
James -----Original Message----- From: Jim Seach [mailto:[EMAIL PROTECTED] Sent: Sunday, April 03, 2005 8:21 PM To: Jakarta Commons Developers List Subject: RE: [PROPOSAL] Commons Runtime API for Persistence James, You are, of course, correct and make a lot of good points. My proposal just adds complexity and doesn't buy you anything over what we get with JDBC. I may have completely misread Geir's proposal, but did you look at the acronym? Also, take a look at the link at the end of my last message. I think this is the spirit in which he made the proposal. ;^) In my view, the Commons Runtime API for Persistence (CRAP) is not really necessary. If you use good application design, it should be relatively easy to move from one tool to another. Also, given the rate of innovation currently happening in this area, it would be premature to try to abstract out a lowest common denominator. I just took Geir's proposal and ran with it in the direction I think he started. :^) Thanks, Jim --- James Carman <[EMAIL PROTECTED]> wrote: > Jim, > > How about this? Why don't you put up some sample code so that we can > see what you envision. At this point, I don't get it. If the JDBC > API was > sufficient in the first place, we wouldn't have ever needed O/R > mapping > technologies to abstract our data sources. Persistence technologies > such as > Hibernate or JDO have many features which JDBC doesn't support in and > of > itself. For example, how do I tell a JDBC connection (or statement) > to > delete an object? There is no delete( Object o ) method in the JDBC > API. > Also, if I want to add an object to the persistence store, I can just > do > save( Object o ) or something similar, but not with JDBC. I have to > construct an insert statement and map the properties in my object to > columns > in the database table (assuming our mapping is just that simple). > Maybe a > code sample would help me/us (I'm assuming others are having trouble > with > this, but it could just be me). How about this. Consider the > following > class... > > public class Person > { > private String firstName; > private String lastName; > private int ssn; > > // Setters/Getters > } > > Now, using the JDBC API (let's assume Commons Persisting is our > driver), how would you... > > 1. Create a Person object in the data store. > 2. Retrieve a Person object from the data store. > 3. Update a Person object in the data store. > 4. Delete a Person object from the data store. > > These are the fundamental CRUD operations that any O/R mapping system > needs to support. I'm not saying that it can't be done using JDBC > (there are many > existing examples to refute that claim). I'm just saying that it's > MUCH > more difficult with JDBC than with Hibernate or JDO, for instance. > > James > > -----Original Message----- > From: Jim Seach [mailto:[EMAIL PROTECTED] > Sent: Sunday, April 03, 2005 4:47 PM > To: Jakarta Commons Developers List > Subject: RE: [PROPOSAL] Commons Runtime API for Persistence > > > 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] > > > > --------------------------------------------------------------------- > 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]
