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 Sun, 03 Apr 2005 23:25:25 GMT
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:jwseach@yahoo.com] 
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 <james@carmanconsulting.com> 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:jwseach@yahoo.com]
> 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 <flamefew@gmail.com> 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 <james@carmanconsulting.com>
> > 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: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
> > > 
> > >
> > 
> >
> ---------------------------------------------------------------------
> > 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
> 
> 


---------------------------------------------------------------------
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