|
Home > Archive > Apache JDO Project > July 2006 > JDO2 Annotations
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Andy Jefferson 2006-06-19, 1:11 pm |
| 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
| |
| Erik Bengtson 2006-06-19, 1:11 pm |
| > > 1c. Completely redefine annotations to align completely with JDO xml
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>:
[vbcol=seagreen]
> Hi Craig,
>
>
>
>
> 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).
>
>
> 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.
>
>
>
> Agreed. I'd include Enum, Calendar, Queue, PriorityQueue as a start.
>
>
> Yes.
>
>
> 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
>
| |
| Andy Jefferson 2006-06-19, 1:11 pm |
| > I prefer option C. Mixing JDO 2 xml and JPA annotations
> sounds like JDO is transforming into JPA
After further review of the JPA annotations definition, and the amount of
configuration missing from JPA, I'm now tending towards option C also. It's not
like JPA has even the basic properties covered, which they don't. There are too
many concepts missing from JPA (not to mention the differing terminology) so JDO
would be defining its own annotations to a high degree anyway, so why not just be
done with it and define JDO annotations?
Clearly any implementation of JDO/JPA can implement their own support for JPA
annotations, but from a purely specification point of view JDO annotations need
to be complete and matching what the metadata provides control over, hence its
own set.
--
Andy
| |
| Andy Jefferson 2006-06-26, 7:11 am |
| For information, you can find an initial (top-level) set of suggested JDO2
annotations at
http://jpox.cvs.sourceforge.net/jpo...ox/annotations/
in case JDO2 decides to adopt its own annotations.
The aim with these is to retain the mapping MetaData<->Annotation (which is what
JPA does, just they dont have such generalised MetaData so cant specify things
that we need). The main annotations are
@PersistenceCapable
class MyClass
{
@PersistentField
String myField;
...
}
@PersistenceAware
class MyAwareClass
{
...
}
The "class" metadata element maps to the "PersistenceCapable" annotation. The
"field" metadata element maps to the "PersistentField" annotation. The only place
where this differs in this sample set is that I split out "PersistenceAware" as
its own annotation.
--
Andy
| |
| Andy Jefferson 2006-07-05, 7:11 am |
| > For information, you can find an initial (top-level) set of suggested JDO2
> annotations at
http://jpox.cvs.sourceforge.net/jpo...ox/annotations/
Since it's all quiet on annotations I'll provoke further :-)
The above link now shows an almost complete set of proposed JDO2 annotations
(I changed "PersistentField" to "Field" to match the metadata element). The
advantages of matching annotations to metadata element are obvious ... people
don't need to relearn the terms they already know from metadata. The only
places where I haven't stuck to this are the top-level PersistenceCapable,
PersistenceAware annotations (since they make more sense, to me)
The only elements missing are Index, ForeignKey, Unique (i'll add these soon),
Interface, Property (which are low interest for me) and the recursive aspects
of FetchGroup and Embedded (which are restricted due to annotations JDK1.5
design). Needless to say that these are all supported in the latest JPOX
nightly builds where you could actually use them interchangeably with your
metadata, or JPA annotations, or indeed your own set of annotations if you
feel like it.
Comments are welcome. Really.
--
Andy
| |
| Craig L Russell 2006-07-12, 1:11 pm |
| | |
| Ilan Kirsh 2006-07-12, 1:11 pm |
| After reviewing Andy's proposal and the relevant page on JPOX website
I vote for:
2. Define a complete set of annotations - based on JPOX current work
And IMO, this should be a required feature.
Ilan
----- Original Message -----
From: "Craig L Russell" <Craig.Russell@sun.com>
To: <jdo-dev@db.apache.org>
Cc: <jdo-experts-ext@sun.com>
Sent: Wednesday, July 12, 2006 7:36 PM
Subject: Re: JDO2 Annotations
> Javadogs,
>
> Please take a look at this proposal by Andy.
>
> High order bit: The expert group needs to make a decision whether to:
>
> 1. Not define any annotations, leaving it up to implementations to
> decide what to do
>
> 2. Define a complete set of annotations
>
> 3. Track JSR 220 and JSR 250 annotations for persistence and mapping
> and add only annotations for JDO that are not already covered by the
> other annotation specifications
>
> Orthogonal to the above, we need to decide whether support of
> annotations for implementations that support JDK 1.5 is required or
> optional.
>
> Craig
>
> On Jul 4, 2006, at 11:48 PM, Andy Jefferson 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 L Russell 2006-07-12, 7:11 pm |
| | |
| Erik Bengtson 2006-07-12, 7:11 pm |
| I believe option 2 is most appropriate for JDO. JDO, really, is actually much
more behavioral predictable than JSR 220, so it really deserves its own
annotation.
However, implementations may just be capable to understand JSR 220 for confort
of the end user. Mostly to help then to "kind of" migrate from JPA to JDO,
particulary I'm refering to usage of the JPA tools that will generate JPA
annotations that could be used by JDO implementations.
> Orthogonal to the above, we need to decide whether support of
> annotations for implementations that support JDK 1.5 is required or
> optional.
I would say yes, speaking for Andy (Andy implemented the annotations stuff), it
was very easy to implement, and in a question of days. I abstain in case of
vote, just in case.
Still I would say add another option:
> 4. Track JSR 220 and JSR 250 annotations for persistence.
and mapping. Have only what is already there and thats all (besides vendor
things)
JPOX is supporting fully or partially option 1 (since 2 is not standard), 3 and
4.
Regards,
Quoting Craig L Russell <Craig.Russell@sun.com>:
> Javadogs,
>
> Please take a look at this proposal by Andy.
>
> High order bit: The expert group needs to make a decision whether to:
>
> 1. Not define any annotations, leaving it up to implementations to
> decide what to do
>
> 2. Define a complete set of annotations
>
> 3. Track JSR 220 and JSR 250 annotations for persistence and mapping
> and add only annotations for JDO that are not already covered by the
> other annotation specifications
>
> Orthogonal to the above, we need to decide whether support of
> annotations for implementations that support JDK 1.5 is required or
> optional.
>
> Craig
>
> On Jul 4, 2006, at 11:48 PM, Andy Jefferson 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!
>
>
| |
| Eric Samson 2006-07-14, 7:11 am |
| Hello Craig and all
Here is why we support option 3:
* we think that annotations are nice for persistence but not for mapping information
* so annotation should remain as simple as possible and stay data source independent
* one goal of a persistence tool is to remove technical APIs to access data sources from business applications source code, mapping annotations are a move backward in that case. Moreover, they tend to make the source code unreadable as it is cluttered with dozens of interpreted comment lines
* it is important for users to have a kind of convergence between JDO and JPA in the future
* to that extent defining a set of completely different annotations is not desirable
* my guess is that ORM tools will have to support both JDO and JPA in the future so it is better to implement only one set of annotations (maybe with additional JDO2 annotations whenever required)
* to me JDO2 is already a superset of JPA, so JDO annotations should be a superset of JPA annotations
Best Regards,
.....: Eric Samson, Founder & CTO, xcalia
Service your Data!
________________________________
De : Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
Envoyé : mercredi 12 juillet 2006 22:06
À : Apache JDO project
Cc : JDO Expert Group
Objet : Re: JDO2 Annotations
Hi Matthew,
With hindsight, do you think that this is the right solution? Any insights from your implementation and usage experience whether it was a good or bad idea?
Craig
On Jul 12, 2006, at 1:02 PM, Matthew T. Adams wrote:
Xcalia supports option 3, reusing JSRs 220 & 250 annotations and defining additional ones as necessary.
--matthew
----- Original Message ----
From: Ilan Kirsh <kirsh@objectdb.com>
To: Craig L Russell <Craig.Russell@Sun.com>; jdo-dev@db.apache.org
Cc: JDO Expert Group <jdo-experts-ext@Sun.com>
Sent: Wednesday, July 12, 2006 12:06:55 PM
Subject: Re: JDO2 Annotations
After reviewing Andy's proposal and the relevant page on JPOX website
I vote for:
2. Define a complete set of annotations - based on JPOX current work
And IMO, this should be a required feature.
Ilan
----- Original Message -----
From: "Craig L Russell" <Craig.Russell@sun.com <mailto:Craig.Russell@sun.com> >
To: <jdo-dev@db.apache.org <mailto:jdo-dev@db.apache.org> >
Cc: <jdo-experts-ext@sun.com <mailto:jdo-experts-ext@sun.com> >
Sent: Wednesday, July 12, 2006 7:36 PM
Subject: Re: JDO2 Annotations
> Javadogs,
>
> Please take a look at this proposal by Andy.
>
> High order bit: The expert group needs to make a decision whether to:
>
> 1. Not define any annotations, leaving it up to implementations to
> decide what to do
>
> 2. Define a complete set of annotations
>
> 3. Track JSR 220 and JSR 250 annotations for persistence and mapping
> and add only annotations for JDO that are not already covered by the
> other annotation specifications
>
> Orthogonal to the above, we need to decide whether support of
> annotations for implementations that support JDK 1.5 is required or
> optional.
>
> Craig
>
> On Jul 4, 2006, at 11:48 PM, Andy Jefferson wrote:
>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo <http://java.sun.com/products/jdo>
> 408 276-5638 mailto:Craig.Russell@sun.com <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!
| |
| Ilan Kirsh 2006-07-14, 7:11 am |
| Another thought about annotations. Because eventually most vendors will
have to provide annotations for their own extensions, users will have to be
familiar with at least two lists of annotations, the standard and the vendor
specific. To simplify things, I think it will be better for users to have
exactly
two lists of annotations and not three or four lists. Therefore, options 1
and 2 are better than option 3 IMO, as well as Erik's suggestion:
> 4. Track JSR 220 and JSR 250 annotations for persistence and mapping.
> Have only what is already there and thats all (besides vendor things)
It just seems that option 3 with annotations from so many different sources
may cause too much mess. For the sake of completeness of the JDO spec
option 2 is preferred. However, if JDO future market is as an extension to
JPA, options 1 or 4 are better.
Ilan
----- Original Message -----
From: "Eric Samson" <eric.samson@xcalia.com>
To: <Craig.Russell@Sun.COM>; "Apache JDO project" <jdo-dev@db.apache.org>
Cc: "JDO Expert Group" <jdo-experts-ext@Sun.COM>
Sent: Friday, July 14, 2006 12:25 AM
Subject: RE: JDO2 Annotations
Hello Craig and all
Here is why we support option 3:
* we think that annotations are nice for persistence but not for mapping
information
* so annotation should remain as simple as possible and stay data source
independent
* one goal of a persistence tool is to remove technical APIs to access data
sources from business applications source code, mapping annotations are a
move backward in that case. Moreover, they tend to make the source code
unreadable as it is cluttered with dozens of interpreted comment lines
* it is important for users to have a kind of convergence between JDO and
JPA in the future
* to that extent defining a set of completely different annotations is not
desirable
* my guess is that ORM tools will have to support both JDO and JPA in the
future so it is better to implement only one set of annotations (maybe with
additional JDO2 annotations whenever required)
* to me JDO2 is already a superset of JPA, so JDO annotations should be a
superset of JPA annotations
Best Regards,
.....: Eric Samson, Founder & CTO, xcalia
Service your Data!
________________________________
De : Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
Envoyé : mercredi 12 juillet 2006 22:06
À : Apache JDO project
Cc : JDO Expert Group
Objet : Re: JDO2 Annotations
Hi Matthew,
With hindsight, do you think that this is the right solution? Any insights
from your implementation and usage experience whether it was a good or bad
idea?
Craig
On Jul 12, 2006, at 1:02 PM, Matthew T. Adams wrote:
Xcalia supports option 3, reusing JSRs 220 & 250 annotations and defining
additional ones as necessary.
--matthew
----- Original Message ----
From: Ilan Kirsh <kirsh@objectdb.com>
To: Craig L Russell <Craig.Russell@Sun.com>; jdo-dev@db.apache.org
Cc: JDO Expert Group <jdo-experts-ext@Sun.com>
Sent: Wednesday, July 12, 2006 12:06:55 PM
Subject: Re: JDO2 Annotations
After reviewing Andy's proposal and the relevant page on JPOX website
I vote for:
2. Define a complete set of annotations - based on JPOX current work
And IMO, this should be a required feature.
Ilan
----- Original Message -----
From: "Craig L Russell" <Craig.Russell@sun.com
<mailto:Craig.Russell@sun.com> >
To: <jdo-dev@db.apache.org <mailto:jdo-dev@db.apache.org> >
Cc: <jdo-experts-ext@sun.com <mailto:jdo-experts-ext@sun.com> >
Sent: Wednesday, July 12, 2006 7:36 PM
Subject: Re: JDO2 Annotations
> Javadogs,
>
> Please take a look at this proposal by Andy.
>
> High order bit: The expert group needs to make a decision whether to:
>
> 1. Not define any annotations, leaving it up to implementations to
> decide what to do
>
> 2. Define a complete set of annotations
>
> 3. Track JSR 220 and JSR 250 annotations for persistence and mapping
> and add only annotations for JDO that are not already covered by the
> other annotation specifications
>
> Orthogonal to the above, we need to decide whether support of
> annotations for implementations that support JDK 1.5 is required or
> optional.
>
> Craig
>
> On Jul 4, 2006, at 11:48 PM, Andy Jefferson wrote:
>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> <http://java.sun.com/products/jdo>
> 408 276-5638 mailto:Craig.Russell@sun.com <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!
| |
| Christian Ernst 2006-07-21, 7:11 am |
| Hi JDO folks,
The Solution we want to propose is based on 2.
1. JDO2 should define an own clear set of Annotations
* JDO2 Annotations are splitted in two seperated sets with two
indipendent packages
* Persistence JDO2 Annotation are defined based on the *.jdo
definition
* Mapping JDO2 Annotations are defined based on the *.orm definition
2. JDO2 should define interopability with EJB3/JPA
* Use of EJB3/JPA Annotations
* Mapping of EJB3/JPA to JDO2 Annotations
* Assumed defaults on missing or different Annotations
cheers
Christian
| |
| Andy Jefferson 2006-07-21, 7:11 am |
| > The Solution we want to propose is based on 2.
>
> 1. JDO2 should define an own clear set of Annotations
> * JDO2 Annotations are splitted in two seperated sets with two
> indipendent packages
> * Persistence JDO2 Annotation are defined based on the *.jdo
> definition
> * Mapping JDO2 Annotations are defined based on the *.orm definition
+1
Clear definition would be good for 2 reasons.
1. Clear dividing line for implementations who don't support ORM
2. Clear definition for users to avoid specifying deployment-level info in
annotations, whilst allowing them the flexibility of doing so if they so
wish.
The only differences from the current JPOX set are packaging (trivial), and
separating out some of the attributes into their own ORM annotation ... e.g
PersistenceCapable has catalog, schema, table attributes, whereas they would
need pulling out into an ORM annotation.
> 2. JDO2 should define interopability with EJB3/JPA
> * Use of EJB3/JPA Annotations
> * Mapping of EJB3/JPA to JDO2 Annotations
> * Assumed defaults on missing or different Annotations
+1
--
Andy
Java Persistent Objects - JPOX
|
|
|
|
|