db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilan Kirsh <ki...@objectdb.com>
Subject Re: A JDO-JPA Bridge
Date Sun, 08 Oct 2006 10:12:56 GMT
Hi Craig,

I don't understand why there is no reason to close a JPA query results but there is a reason
to close a JDO query results or a JDBC ResultSet. What is the difference? Query results might
hold an expansive resources on the server. This can usually be released in a finalize method.
But sometimes it is better 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 ordinal parameters
+ named parameters, therefore both methods of argument providing (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 issue. No real damage
can occur also for not having it. I am glad that you like the general idea. Having JEntityManagerFactory,
JEntityManager and JEntityTransaction might be good enough for me.



----- 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 allow 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, use a JDO Query.
Why mix?


  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 methods for JPQL queries (mainly
the close and closeAll methods are useful). This can also be achieved by a new JDOHelper method
if the JQuery interface causes 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.Query
in the future for the sake of both JDOQL and JPQL, so JQuery might be useful. Exceptions can
be thrown when irrelevant methods of javax.jdo.Query are invoked for a JPQL query.



    ----- 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:
    >> 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 the 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 datastore 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 interesting. Of course, similar examples can be written  
    >> also for the other direction (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 more 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 there is EntityManager but there  
    >> is also JEntityManager that supports additional 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  
    >> majority of the JPA implementations might be also JDO  
    >> implementations. In that case, JEntityManagerFactory,  
    >> JEntityManager, JEntityTransaction, JQuery, JDOHelper 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  
    >> explanation.
    >> Actually the maximum is not so far from the minimum:
    >> - New section in the specification that explains this addition with  
    >> more details 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 because 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  
    >> interested).
    >> 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
    > 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!

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message