db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Bengtson <e...@jpox.org>
Subject Re: JDO2 Annotations
Date Mon, 19 Jun 2006 13:02:39 GMT
> > 1c. Completely redefine annotations to align completely with JDO xml
> > metadata. With this approach, you would not be able to take advantage
> > of tools that generate 220 annotations.

I prefer option C. Mixing JDO 2 xml and JPA annotations sounds like JDO is
transforming into JPA. However the wave of tools coming with JPA is not
inconsiderable. I propose that JDO optionally allow JDO ORM implementations to
entirelly use the JPA xml and JPA annotations, which would also allow easy
migration from JPA to JDO ;) More, I also think that JDO should optionally
allow implementations to use JPQL.

Regards,

Erik Bengtson

Quoting Andy Jefferson <andy@jpox.org>:

> Hi Craig,
>
> > 1. Add annotations to persistence capable classes.
>
> > 1a. Use the 220 annotations including the package names
> > and add JDO-specific annotations to them.
>
> > 1b. Use just the 220 annotation names but repackage them from
> > javax.persistence to javax.jdo.annotations or something similar.
> > This would give us the opportunity (and the danger) of redefining
> > the semantics of some of the annotations without conflicting with
> > the 220 spec. For example, we could redefine the default behavior
> > of fetching relationship fields from eager to lazy, which cannot
> > be done with 1a.
>
> If we repackage the JPA annotations into say "javax.jdo.annotations" then
> wouldn't we lose the advantage of tools that create 220 annotations since
> those
> tools also add in the necessary imports for such annotations (and they would
> be
> in different locations) ? so its similar to c).
>
> > 1c. Completely redefine annotations to align completely with JDO xml
> > metadata. With this approach, you would not be able to take advantage
> > of tools that generate 220 annotations.
>
> Certainly a) is the first step since we will need annotations adding for the
> non-JPA parts of JDO2.
> My preference would probably be to stick to the JPA variants where possible,
> and
> if they dont fit our needs then we can either copy the JPA variant, or maybe
> inherit from them to add on extra fields.
>
> From an implementation viewpoint there is not much difference in time to
> implement a complete set of JDO2 annotations as opposed to JPA + addon-JDO2
> annotations.
>
>
> In addition, a definition of what has the higher priority (annotations,
> metadata)
> would be required to be added to the spec. For example, use annotations, and
> then
> metadata would override the annotations specification. As per JPA spec
> section 10.
>
>
> > 2. Add support for enums and highly concurrent collections.
>
> Agreed. I'd include Enum, Calendar, Queue, PriorityQueue as a start.
>
> > 3. Change signatures of interface methods to be 1.5 friendly.
> > For example, the signatures of the makePersistent methods should
> > be changed to:
> > <T> T makePersistent(T pc);
> > <T> Collection<T> makePersistent(Collection<T> pcs);
> > <T> T[] makePersistent(T[] pcs);
>
> Yes.
>
> > 4. Distribute multiple jar files that represent the 1.5 interfaces.
> > The interfaces that are 1.5-specific cannot be packaged in a jar
> > file with the 1.3 declarations of the interfaces.
> > Right now, the jar is named:
> > javax.jdo/jars/jdo2-api-2.0.jar. What needs to change for 1.5?
> > Perhaps javax.jdo/jars/jdo2-1.5-api-2.0.1.jar would work.
>
> There would have to be 2 jars. The above name is fine with me, though may be
> more
> explicit to call it
> javax.jdo/jars/jdo2-jdk1.5-api-2.0.1.jar
> so people know what the 1.5 stands for.
>
> --
> Andy
>




Mime
View raw message