Hi all,

Following is an enhancement suggestion for JDO 2.1 (or maybe even for JDO 2.
01?) that may give maximum results in minimum effort.

I suggest to add four new interfaces to javax.jdo (or to a sub package):

public interface JEntityManagerFactory extends
javax.persistence.EntityManagerFactory, javax.jdo.PersistenceManagerFactory
{
}

public interface JEntityManager extends
javax.persistence.EntityManager, javax.jdo.PersistenceManager
{
}

public interface JEntityTransaction extends
javax.persistence.EntityTransaction, javax.jdo.Transaction
{
}

public interface JQuery extends
javax.persistence.Query, javax.jdo.Query
{
}

JDO 2.1 Implementations that will support the new optional "javax.jdo.option
.JPA" feature will have to return instances of these interfaces instead of t
he super interfaces when using either the JDO API or the JPA API.

For instance, a JDO 2.1 implementation with JPA 1.0 support will support dat
astore transactions (currently only optimistic transactions are supported by
 JPA):

EntityManagerFactory emf = Persistence.createEntityManagerFactory("myUnit");
EntityManager em = emf.createEntityManager();
((JEntityTransaction)em.getTransaction()).setOptimistic(false);

And will support using Extent (no Extent in JPA and I think that there is no
 support for filtering subclasses, at least not in an easy way):

EntityManagerFactory emf = Persistence.createEntityManagerFactory("myUnit");
EntityManager em = emf.createEntityManager();
Extent extent = ((JEntityManager)em).getExtent(MyClass, false);

As well as many other things that are missing in JPA, for example:

boolean isDirty = JDOHelper.isDirty(entity);
EntityManager em = (EntityManager)JDOHelper.getPersistenceManager(entity);

These examples are for using JPA with JDO extensions which I think is more i
nteresting. Of course, similar examples can be written also for the other di
rection (using JPA from JDO).

The names of the new four interfaces is based on the JPA interface names in 
a way that may suggest that they are more powerful. Which do you consider mo
re powerful AWT Frame, Panel and Button or Swing JFrame, JPanel and JButton?
 If JPA will catch then every curious Java developer will soon know that the
re is EntityManager but there is also JEntityManager that supports additiona
l operations and unlike Hibernate or TopLink extensions is supported by many
 vendors and backed by a standard! I agree with David that some day the majo
rity of the JPA implementations might be also JDO implementations. In that c
ase, JEntityManagerFactory, JEntityManager, JEntityTransaction, JQuery, JDOH
elper and Extent may be something significant that cannot be ignored in the 
JPA market.

The minimum that is required in order to support this addition in JDO 2.1 is
:
- Adding the four new interfaces.
- Adding "javax.jdo.option.JPA" to the specification with a short explanatio
n.

Actually the maximum is not so far from the minimum:
- New section in the specification that explains this addition with more det
ails and maybe some examples.
- Handling possible conflicts (e,g, which exceptions are thrown JDO or JPA?)
.
- TCK tests that check that an implementation that claims to support "javax.
jdo.option.JPA" indeed returns instances of the new four interfaces.

Of course, no need to describe the JPA in the JDO spec or write JPA tests be
cause all this is already handled by the EJB 3 spec.

Accepting this suggestion will enable using JDO in two modes:
1. Standalone (for current users as well as for new users that are intereste
d).
2. As an extension to JPA (might be very useful if JPA will catch).

Any comments will be welcomed.

Regards,

Ilan Kirsh
ObjectDB Software
http://www.objectdb.com

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

Hi Craig,

I wasn't sure about the JQuery interface either, but eventually I decided to
 include it in my suggestion to provide the compile, close and closeAll meth
ods for JPQL queries (mainly the close and closeAll methods are useful). Thi
s can also be achieved by a new JDOHelper method if the JQuery interface cau
ses too much trouble (which I hope does not) but it complicates things. Also
 there may be additional methods that we might want to add to javax.jdo.Quer
y in the future for the sake of both JDOQL and JPQL, so JQuery might be usef
ul. Exceptions can be thrown when irrelevant methods of javax.jdo.Query are 
invoked for a JPQL query.

Regards,

Ilan

----- Original Message ----- 
From: "Craig L Russell" <Craig.Russell@Sun.COM>
To: <jdo-dev@db.apache.org>
Cc: "JDO Expert Group" <jdo-experts-ext@Sun.COM>
Sent: Sunday, October 08, 2006 3:03 AM
Subject: Re: A JDO-JPA Bridge


> Hi Ilan,
> 
> Thanks for this. I've been thinking for a while that JDO is an  
> extension of JPA and this makes sense.
> 
> I don't know why the JQuery interface is needed. The query interfaces  
> of JDO and JPA are different enough that I don't know why you would  
> want to mix them.
> 
> Craig
> 
> On Oct 7, 2006, at 11:08 AM, Ilan Kirsh wrote:
>  
> 
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
> 
>

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

Hi Craig,

I don't understand why there is no reason to close a JPA query results but t
here is a reason to close a JDO query results or a JDBC ResultSet. What is t
he difference? Query results might hold an expansive resources on the server
. This can usually be released in a finalize method. But sometimes it is bet
ter not to wait for the GC and then to the finalizer. Wasn't this the reason
 to include these methods in JDO in the first place?

The parameter binding is not so different. Both query languages support ordi
nal parameters + named parameters, therefore both methods of argument provid
ing (execute / setParameter) can work for queries of both types.

I didn't notice the Serializable difference but that might be another reason
 for having JQuery. Ordinary JPA Query cannot be serialized but JQuery can (
even though it is unclear if anyone is using it).

However, I think that having or not having a JQuery interface is a minor iss
ue. No real damage can occur also for not having it. I am glad that you like
 the general idea. Having JEntityManagerFactory, JEntityManager and JEntityT
ransaction might be good enough for me.

Regards,

Ilan


----- Original Message ----- 
From: Craig L Russell 
To: Ilan Kirsh 
Cc: jdo-dev@db.apache.org 
Sent: Sunday, October 08, 2006 6:34 AM
Subject: Re: A JDO-JPA Bridge


Hi Ilan, 


I've looked at the JPA Query interface and I'm totally not impressed. There'
s no reason to close a Query. The parameter binding is hopeless. There is no
 notion of serializing a query. I don't see anything in common that would al
low you to construct a JPA query and use the JDO query API with it, so I don
't see any need to return a JPDOQuery instance from either API. 


If you use EntityManager, use a JPA Query. If you use PersistenceManager, us
e a JDO Query. Why mix?


Craig


On Oct 7, 2006, at 6:29 PM, Ilan Kirsh wrote:


Hi Craig,

I wasn't sure about the JQuery interface either, but eventually I decided to
 include it in my suggestion to provide the compile, close and closeAll meth
ods for JPQL queries (mainly the close and closeAll methods are useful). Thi
s can also be achieved by a new JDOHelper method if the JQuery interface cau
ses too much trouble (which I hope does not) but it complicates things. Also
 there may be additional methods that we might want to add to javax.jdo.Quer
y in the future for the sake of both JDOQL and JPQL, so JQuery might be usef
ul. Exceptions can be thrown when irrelevant methods of javax.jdo.Query are 
invoked for a JPQL query.

Regards,

Ilan

----- Original Message ----- 
From: "Craig L Russell" <Craig.Russell@Sun.COM>
To: <jdo-dev@db.apache.org>
Cc: "JDO Expert Group" <jdo-experts-ext@Sun.COM>
Sent: Sunday, October 08, 2006 3:03 AM
Subject: Re: A JDO-JPA Bridge


> Hi Ilan,
> 
> Thanks for this. I've been thinking for a while that JDO is an  
> extension of JPA and this makes sense.
> 
> I don't know why the JQuery interface is needed. The query interfaces  
> of JDO and JPA are different enough that I don't know why you would  
> want to mix them.
> 
> Craig
> 
> On Oct 7, 2006, at 11:08 AM, Ilan Kirsh wrote:
>  
> 
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
> 
>




Craig Russell

Architect, Sun Java Enterprise System http://java.sun.com/products/jdo

408 276-5638 mailto:Craig.Russell@sun.com

P.S. A good JDO? O, Gasp!

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

An interesting side effect of the suggested JDO-JPA bridge is that JDO gets 
Java EE integration for free! Spring supports JDO but probably EJB based app
lication servers will never do (at least directly).

But look at this:

@Stateless
public class EmployeeServiceBean {
@PersistenceContext(unitName="MyUnit") JEntityManager pm;

public void addEmployee(String name)
{
Employee employee = new Employee(name);
pm.makePersistent(employee);
}

:
:
}

This is even better than the EntityManager's getDelegate hook method. Simila
r injection can be used also for JEntityManagerFactory when necessary. I jus
t hope that a field that is annotated with @PersistenceContext can be of a s
ubtype of EntityManager (if not an additional field and a casting in a @Post
Construct method might be needed, maybe this can be inherited and implemente
d once for the entire project).

Notice that also JDO implementations with no full JPA support can gain from 
this by implementing JEntityManager and the other new interfaces and throwin
g NotSupported exceptions in most JPA methods. Only support for initializati
on from persistence.xml file and a few JPA methods is required (very simple)
 . Of course, such an implementation is not expected to claim for "javax.jdo
.option.JPA" support.

It seems that the new pluggable provider architecture of EJB 3.0 can work gr
eat for JDO!


----- Original Message ----- 
From: Ilan Kirsh 
To: jdo-dev@db.apache.org ; JDO Expert Group 
Sent: Saturday, October 07, 2006 8:08 PM
Subject: A JDO-JPA Bridge


Hi all,

Following is an enhancement suggestion for JDO 2.1 (or maybe even for JDO 2.
01?) that may give maximum results in minimum effort.

I suggest to add four new interfaces to javax.jdo (or to a sub package):

public interface JEntityManagerFactory extends
javax.persistence.EntityManagerFactory, javax.jdo.PersistenceManagerFactory
{
}

public interface JEntityManager extends
javax.persistence.EntityManager, javax.jdo.PersistenceManager
{
}

public interface JEntityTransaction extends
javax.persistence.EntityTransaction, javax.jdo.Transaction
{
}

public interface JQuery extends
javax.persistence.Query, javax.jdo.Query
{
}

JDO 2.1 Implementations that will support the new optional "javax.jdo.option
.JPA" feature will have to return instances of these interfaces instead of t
he super interfaces when using either the JDO API or the JPA API.

For instance, a JDO 2.1 implementation with JPA 1.0 support will support dat
astore transactions (currently only optimistic transactions are supported by
 JPA):

EntityManagerFactory emf = Persistence.createEntityManagerFactory("myUnit");
EntityManager em = emf.createEntityManager();
((JEntityTransaction)em.getTransaction()).setOptimistic(false);

And will support using Extent (no Extent in JPA and I think that there is no
 support for filtering subclasses, at least not in an easy way):

EntityManagerFactory emf = Persistence.createEntityManagerFactory("myUnit");
EntityManager em = emf.createEntityManager();
Extent extent = ((JEntityManager)em).getExtent(MyClass, false);

As well as many other things that are missing in JPA, for example:

boolean isDirty = JDOHelper.isDirty(entity);
EntityManager em = (EntityManager)JDOHelper.getPersistenceManager(entity);

These examples are for using JPA with JDO extensions which I think is more i
nteresting. Of course, similar examples can be written also for the other di
rection (using JPA from JDO).

The names of the new four interfaces is based on the JPA interface names in 
a way that may suggest that they are more powerful. Which do you consider mo
re powerful AWT Frame, Panel and Button or Swing JFrame, JPanel and JButton?
 If JPA will catch then every curious Java developer will soon know that the
re is EntityManager but there is also JEntityManager that supports additiona
l operations and unlike Hibernate or TopLink extensions is supported by many
 vendors and backed by a standard! I agree with David that some day the majo
rity of the JPA implementations might be also JDO implementations. In that c
ase, JEntityManagerFactory, JEntityManager, JEntityTransaction, JQuery, JDOH
elper and Extent may be something significant that cannot be ignored in the 
JPA market.

The minimum that is required in order to support this addition in JDO 2.1 is
:
- Adding the four new interfaces.
- Adding "javax.jdo.option.JPA" to the specification with a short explanatio
n.

Actually the maximum is not so far from the minimum:
- New section in the specification that explains this addition with more det
ails and maybe some examples.
- Handling possible conflicts (e,g, which exceptions are thrown JDO or JPA?)
.
- TCK tests that check that an implementation that claims to support "javax.
jdo.option.JPA" indeed returns instances of the new four interfaces.

Of course, no need to describe the JPA in the JDO spec or write JPA tests be
cause all this is already handled by the EJB 3 spec.

Accepting this suggestion will enable using JDO in two modes:
1. Standalone (for current users as well as for new users that are intereste
d).
2. As an extension to JPA (might be very useful if JPA will catch).

Any comments will be welcomed.

Regards,

Ilan Kirsh
ObjectDB Software
http://www.objectdb.com

[ Post a follow-up to this message ]

Hi all,

 

We've already implemented something like that.

It won't be a big deal to make it compliant with the final names once we wil
l have agreed upon them.

 

Considering that EJBQL3 is de facto supported as JDO support optional query 
languages, we just have to define compliant annotations and then JDO2 won't 
be far from being a superset of EJB3/JPA.

 

Best Regards,

....: Eric Samson, Founder & CTO, xcalia

Service your Data!

________________________________

De : Ilan Kirsh [mailto:kirsh@objectdb.com] 
Envoyé : samedi 7 octobre 2006 20:09
À : jdo-dev@db.apache.org; JDO Expert Group
Objet : A JDO-JPA Bridge

 

Hi all,

Following is an enhancement suggestion for JDO 2.1 (or maybe even for JDO 2.
01?) that may give maximum results in minimum effort.

I suggest to add four new interfaces to javax.jdo (or to a sub package):

public interface JEntityManagerFactory extends
javax.persistence.EntityManagerFactory, javax.jdo.PersistenceManagerFactory
{
}

public interface JEntityManager extends
javax.persistence.EntityManager, javax.jdo.PersistenceManager
{
}

public interface JEntityTransaction extends
javax.persistence.EntityTransaction, javax.jdo.Transaction
{
}

public interface JQuery extends
javax.persistence.Query, javax.jdo.Query
{
}

JDO 2.1 Implementations that will support the new optional "javax.jdo.option
.JPA" feature will have to return instances of these interfaces instead of t
he super interfaces when using either the JDO API or the JPA API.

 

For instance, a JDO 2.1 implementation with JPA 1.0 support will support dat
astore transactions (currently only optimistic transactions are supported by
 JPA):

 

EntityManagerFactory emf = Persistence.createEntityManagerFactory("myUnit");

EntityManager em = emf.createEntityManager();

((JEntityTransaction)em.getTransaction()).setOptimistic(false);

 

And will support using Extent (no Extent in JPA and I think that there is no
 support for filtering subclasses, at least not in an easy way):

 

EntityManagerFactory emf = Persistence.createEntityManagerFactory("myUnit");

EntityManager em = emf.createEntityManager();

Extent extent = ((JEntityManager)em).getExtent(MyClass, false);

 

As well as many other things that are missing in JPA, for example:

 

boolean isDirty = JDOHelper.isDirty(entity);

EntityManager em = (EntityManager)JDOHelper.getPersistenceManager(entity);

 

These examples are for using JPA with JDO extensions which I think is more i
nteresting. Of course, similar examples can be written also for the other di
rection (using JPA from JDO).

 

The names of the new four interfaces is based on the JPA interface names in 
a way that may suggest that they are more powerful. Which do you consider mo
re powerful AWT Frame, Panel and Button or Swing JFrame, JPanel and JButton?
 If JPA will catch then every curious Java developer will soon know that the
re is EntityManager but there is also JEntityManager that supports additiona
l operations and unlike Hibernate or TopLink extensions is supported by many
 vendors and backed by a standard! I agree with David that some day the majo
rity of the JPA implementations might be also JDO implementations. In that c
ase, JEntityManagerFactory, JEntityManager, JEntityTransaction, JQuery, JDOH
elper and Extent may be something significant that cannot be ignored in the 
JPA market.

 

The minimum that is required in order to support this addition in JDO 2.1 is
:

- Adding the four new interfaces.

- Adding "javax.jdo.option.JPA" to the specification with a short explanatio
n.

 

Actually the maximum is not so far from the minimum:

- New section in the specification that explains this addition with more det
ails and maybe some examples.

- Handling possible conflicts (e,g, which exceptions are thrown JDO or JPA?)
.

- TCK tests that check that an implementation that claims to support "javax.
jdo.option.JPA" indeed returns instances of the new four interfaces.

 

Of course, no need to describe the JPA in the JDO spec or write JPA tests be
cause all this is already handled by the EJB 3 spec.

 

Accepting this suggestion will enable using JDO in two modes:

1. Standalone (for current users as well as for new users that are intereste
d).

2. As an extension to JPA (might be very useful if JPA will catch).

 

Any comments will be welcomed.

 

Regards,

 

Ilan Kirsh

ObjectDB Software

http://www.objectdb.com

 

[ Post a follow-up to this message ]