Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
From: Andy Jefferson <andy@jpox.org>
To: jdo-dev@db.apache.org,
 JDO Expert Group <jdo-experts-ext@sun.com>
Subject: Re: The Future of JDO
Date: Thu, 5 Oct 2006 07:08:30 +0200
User-Agent: KMail/1.8.2
References: <011801c6e818$b8df7830$0500000a@ILANC>
 <7444A947-46B0-4689-B3EC-E0301EB0ABBA@bellsouth.net>
In-Reply-To: <7444A947-46B0-4689-B3EC-E0301EB0ABBA@bellsouth.net>
Organization: JPOX
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200610050708.30655.andy@jpox.org>

> I continue to believe that the largest backers of JPA were against
> JDO because of it being binary compatible across object and
> relational databases.

Agreed.

JPA was "invented" to be so weak that Hibernate and TopLink could be 
considered "standards compliant" and to water down any such specification to 
allow such RDBMS vendors (you know who they are) to continue to lock clients 
in to their bloated RDBMS ... another reason why the JDBC "specification" is 
also so weak (and it has had *many* revisions) and doesn't define so many 
things (and why the JDBC drivers of aforementioned RDBMS vendors are so poor 
at implementing that "specification").

> > If, however, JDO 3.0
> > will extend JPA in some way - we might be in a similar position
> > as Hibernate and Toplink that also support their old API in
> > addition to the new JPA API, with the advantage that our extensions
> > are standard and backed by multiple implementations including both
> > relational databases and object databases (plus some unique
> > powerful features such as JDO 2.0 fetch groups).
> > Maybe some JPA issues can be excluded. But in my opinion at least
> > supporting the new API (e.g. deprecating makePersistent and adding
> > persist, or supporting both as in java.util.Vector since JDK 1.2)
> > is a must in order to survive.

Totally agree. I would think of the following items

1. "persistence.xml". I see no real reason not to allow specification of 
classes to be persisted using persistence.xml as an additional way of 
creating the PMF.

2. Persistence API. There are not many differences between JPA and JDO methods 
so what you propose should be straightforward. Those JDO implementations that 
have/are implementing JPA will know that it is simply putting a wrapper 
around their existing JDO method. Why not include in 2.1?

3. Query Language. JPQL can be made available via the query "language" flag in 
the existing API (so we add "javax.jdo.query.JPQL" or something as a valid 
value). OK the JDO implementation (if supporting this language) will have to 
add a new query language but the hook is there. Could be an optional feature 
in JDO 2.1 ?

4. Types. Mandate support for Enums, Calendar when running under Java5, so all 
types that JPA supports are there. Why not include in 2.1?

5. Annotations. The donated JDO2 annotations need splitting between 
persistence annotations, and ORM. Looking through the JPA annotations some 
time ago, it wasn't clear that we can just take theirs and add others due to 
too many missing concepts. What the JDO(3) spec could do is firstly define 
the precedence of annotations and metadata (to match the JPA spec 
definition), and secondly define how JPA annotations can be used by a JDO3 
implementation. In addition provide JDO2/3 annotations to allow finer 
definition.


-- 
Andy