db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: A JDO-JPA Bridge
Date Sun, 08 Oct 2006 16:43:37 GMT
Hi Ilan,

On Oct 8, 2006, at 3:12 AM, Ilan Kirsh wrote:

> Hi Craig,
>
...snip...
>
> 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.

It is an interesting idea.

Craig
>
> 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 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?
>
> 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 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.
>>
>> 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:
>> >
>> >> 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!
>
>
>

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!


Mime
View raw message