|
Home > Archive > Apache JDO Project > October 2007 > JDO 2.1 specification draft can be reviewed...
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]
| Author |
JDO 2.1 specification draft can be reviewed...
|
|
| Craig L Russell 2007-08-04, 1:11 am |
| | |
| Michelle Caisse 2007-08-04, 7:11 pm |
| Hi Craig,
Chapter 19 says: "If xml metadata is defined for annotated classes,
fields, or properties, xml metadata overrides the annotation." I think
there needs to be further discussion about what level the override
happens on. Are all of the annotations in the class automatically
overriden if there is xml for the class, does the override happen only
for annotations for which there is a corresponding xml element, ...?
-- Michelle
Craig L Russell wrote:
> at http://db.apache.org/jdo/documentation.html
>
> Check it out, and send comments...
>
> 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!
>
| |
| cbeams 2007-08-04, 7:11 pm |
|
Good question, Michelle. My first interpretation when reading that
paragraph is that it would be your latter option, where XML can be
'mixed in' with annotations, overriding any that already exist on an
individual basis. As a user, I would expect this. It is especially
important when considering separating out ORM-specific metadata into
XML. For example, I would want to be able to specify *what* is
persistent in annotations, and *how*/*where* it is persisted in XML.
Speaking from my current experience with using 2.1 annotations in a
large code base, we're putting everything, including ORM metadata in
annotations. This is largely to keep things simple. It's much
easier for the uninitiated to deal with all the metadata being in
annotations in the classes they care about than having to know about,
track down, and understand the package.jdo XML. However, I can see
a day coming when we will need to deploy all or part of the code base
against multiple, somewhat differing data models, and it would be
nice to be able to override the hard-coded ORM annotations in XML.
Hopefully that doesn't make for an implementation nightmare :-)
At any rate, thanks for bringing this up. It'll be nice to have the
spec be particular on this topic, one way or the other.
- Chris Beams
On Aug 4, 2007, at 2:02 PM, Michelle Caisse wrote:
> Hi Craig,
>
> Chapter 19 says: "If xml metadata is defined for annotated classes,
> fields, or properties, xml metadata overrides the annotation." I
> think there needs to be further discussion about what level the
> override happens on. Are all of the annotations in the class
> automatically overriden if there is xml for the class, does the
> override happen only for annotations for which there is a
> corresponding xml element, ...?
>
> -- Michelle
>
> Craig L Russell wrote:
>
>
| |
| cbeams 2007-08-04, 7:11 pm |
|
Craig,
The introduction's preamble reads:
> Currently, aside from JDO, there are three Java standards for
> storing Java data persistently: serial-
> ization, JDBC, and Enterprise JavaBeans. Serialization preserves
> relationships among a graph of
> Java objects, but does not support sharing among multiple users.
> JDBC requires the user to explic-
> itly manage the values of fields and map them into relational
> database tables. Enterprise JavaBeans
> require a container in which to run.
There's no mention of JPA here; I imagine there should be, as it is
indeed a fourth standard. Perhaps it's out of scope or
inappropriate, but it would be nice to see the spec 'officially'
address the relationship between these two increasingly similar
standards.
Thanks,
- Chris Beams
> From: Craig L Russell <Craig.Russell@Sun.COM>
> Date: August 3, 2007 7:04:52 PM PDT
> To: Apache JDO project <jdo-dev@db.apache.org>, JDO Expert Group
> <jdo-experts-ext@Sun.COM>
> Subject: JDO 2.1 specification draft can be reviewed...
>
>
> at http://db.apache.org/jdo/documentation.html
>
> Check it out, and send comments...
>
> 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!
>
| |
| cbeams 2007-08-04, 7:11 pm |
| Not to belabor the point here, but reading on I see the following in
section 2.2 ("Rationale"):
> There is no existing Java platform specification that proposes a
> standard architecture for storing the
> state of Java objects persistently in transactional datastores.
Not exactly the case anymore. I suggest this passage be updated (or
eliminated) in light of JPA. Perhaps the statement could be amended
to point out that there is no existing spec that proposes a
*datastore-agnostic* standard architecture for persistence. This is
probably the chief conceptual discriminator between JDO and JPA
today. No flame bait intended on this thread, btw; I'm a JDO user
and advocate. I mention these things because I believe it's in JDO's
best interest to acknowledge JPA wherever appropriate, and
distinguish itself and it's raison d'être wherever it can.
- Chris
On Aug 4, 2007, at 3:49 PM, cbeams wrote:
>
> Craig,
>
> The introduction's preamble reads:
>
>
> There's no mention of JPA here; I imagine there should be, as it is
> indeed a fourth standard. Perhaps it's out of scope or
> inappropriate, but it would be nice to see the spec 'officially'
> address the relationship between these two increasingly similar
> standards.
>
> Thanks,
>
> - Chris Beams
>
>
>
| |
| cbeams 2007-08-05, 1:11 am |
|
Craig, all,
This isn't so much a comment on the 2.1 spec changes, but rather a
suggestion for an addition to the JDOHelper interface in the 2.1
timeline (I don't know if it's too late for this sort of thing)...
JPOX's JPOXJDOHelper implementation exposes a very useful method with
the following signature:
String getObjectState(Object pc)
I would love to see this method exposed by the standard JDOHelper
interface. The spec currently provides status interrogation methods
(per section 8.5), but they're primarily useful assuming one is
testing for a particular state. For example, I might care to assert
that a pc is 'detached-dirty':
assert pc.isDetached() && pc.isDirty();
That's not so bad; it's even elegant. But if I'm debugging my way
through an application, there's no standardized way (that I know of)
to simply print out the state of the pc object. Using JPOX
internals, I can do the following:
logger.debug(JPOXJDOHelper.getObjectState(pc)); // prints out
'detached-dirty', 'transient-clean', or whatever the state actually is.
or, just as easily:
assert "detached-dirty".equals(JPOXJDOHelper.getObjectState(pc));
This method is most useful from a practical point of view:
debugging. One might argue that such code need not be portable and
thus standardized, but I'd counter with "why not"? State transitions
in JDO are complex enough; if we can make the standard interface for
interrogation of those states friendlier, all the better.
IMHO, the only problem with the current JPOX getObjectState()
implementation is that it's string-based. If this method were to be
considered for the 2.1 JDOHelper interface, I would suggest that the
return type be an enumeration that contains identifiers for all the
object states, optional and required:
package javax.jdo;
public interface JDOHelper {
// ...
ObjectState getObjectState(Object pc);
}
Where ObjectState is defined as:
package javax.jdo;
public enum ObjectState {
TRANSIENT,
TRANSIENT_CLEAN,
TRANSIENT_DIRTY,
PERSISTENT_NEW,
PERSISTENT_NONTRANSACTIONAL,
PERSISTENT_NONTRANSACTIONAL_DIRTY,
PERSISTENT_CLEAN,
PERSISTENT_DIRTY,
HOLLOW,
PERSISTENT_DELETED,
PERSISTENT_NEW_DELETED,
DETACHED_CLEAN,
DETACHED_DIRTY;
}
With this addition in place, the user gets the best of both worlds.
Asserting for a given state is trivially easy:
assert JDOHelper.getObjectState(pc) == ObjectState.DETACHED_DIRTY;
And determining object state with no a priori knowledge is simple, too:
logger.debug(JDOHelper.getObjectState(pc)); // prints out
"DETACHED_DIRTY"
The ObjectState enum could also override toString() such that it
transforms the all-caps-and-underscores identifier to the lower-case-
and-dashes format used within the spec, e.g.: DETACHED_DIRTY.toString
() returns "detached-dirty"
Thanks for considering,
- Chris Beams
> From: Craig L Russell <Craig.Russell@Sun.COM>
> Date: August 3, 2007 7:04:52 PM PDT
> To: Apache JDO project <jdo-dev@db.apache.org>, JDO Expert Group
> <jdo-experts-ext@Sun.COM>
> Subject: JDO 2.1 specification draft can be reviewed...
>
>
> at http://db.apache.org/jdo/documentation.html
>
> Check it out, and send comments...
>
> 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 2007-08-05, 1:11 am |
| | |
| Craig L Russell 2007-08-05, 1:11 am |
| | |
| cbeams 2007-08-05, 1:11 am |
| Craig, all
Several suggestions relating to evolving the API in support of Java5
features:
11.6, "Optional Feature Support":
The current draft specifies the signature
Collection supportedOptions();
then continues to read
"This method returns a Collection of String [...]"
This suggests that the signature should be
Collection<String> supportedOptions();
14.6.1, "Query Execution"
I suggest we eliminate
Object execute(Object p1);
Object execute(Object p1, Object p2);
Object execute(Object p1, Object p2, Object p3);
and deprecate
Object executeWithArray(Object[] parameters);
in favor of a newly added
Object execute(Object... parameters);
This new method would seamlessly support any existing calls to the
three eliminated methods, and is a proper replacement for
executeWithArray().
This would would leave us with three (non-deprecated) execution
methods off the Query interface:
Object execute();
Object execute(Object... parameters);
Object executeWithMap(Map parameters);
A slightly more radical approach to this evolution would have us also
eliminate
Object execute();
because the new varargs method can by definition support calls
without arguments,
and deprecate
Object executeWithMap(Map params);
in favor of a new
Object execute(Map params);
because Java can disambiguate between calls to execute(Object...
params) and execute(Map params) just fine. This is predecated by the
assumption that it would never be valid to pass a Map instance as a
first-class query parameter. That might be a faulty assumption, it
might also just be confusing.
If all these changes were made, we'd be left with an execution API
consisting of just two methods:
Object execute(Object... params);
Object execute(Map params);
This is, I believe, technically favorable and cleaner, but technical
considerations are not the only valid ones. Leaving the no-arg
execute() might be friendly to folks that don't understand varargs, etc.
14.8, "Deletion by Query":
The rationale used above for paring down Query's execute methods
could also be applied to Query's deletePersistentAll methods. It
would be legal and Java5-ish to eliminate the no-arg
deletePersistentAll method and reduce the API down to:
long deletePersistentAll(Object... params);
long deletePersistentAll(Map params);
....
There's a number of other places in the spec changes like the ones
mentioned here could be made, but I might be getting ahead of
myself :-) I'll await comments before touching on anything else.
Thanks,
- Chris Beams
> From: Craig L Russell <Craig.Russell@Sun.COM>
> Date: August 3, 2007 7:04:52 PM PDT
> To: Apache JDO project <jdo-dev@db.apache.org>, JDO Expert Group
> <jdo-experts-ext@Sun.COM>
> Subject: JDO 2.1 specification draft can be reviewed...
>
>
> at http://db.apache.org/jdo/documentation.html
>
> Check it out, and send comments...
>
> 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 2007-08-05, 1:11 am |
| | |
| Andy Jefferson 2007-08-05, 1:11 am |
| Hi,
[vbcol=seagreen]
> I'd like to see others' reaction to this proposal as well.
I clearly think it's a good idea since that's why JPOX has it ;-)
Anything that adds more information to the user domain and more clearly=20
defines the object states is a good thing.
I agree with the principle of making the return an enum (for the "api21" ja=
r -=20
obviously can't be like that in the legacy jar since that has to support=20
1.3+). The only issue is that HOLLOW and P_NONTRANS have the same=20
combinations of the various "isPersistent", "isTransactional", etc fields a=
nd=20
that is why the JPOX method outputs "hollow / persistent-nontransactional"
=2D-=20
Andy =A0(Java Persistent Objects - http://www.jpox.org)
| |
| David Ezzio (asmtp) 2007-08-13, 1:11 pm |
|
Andy Jefferson wrote:
> Hi,
>
>
> I clearly think it's a good idea since that's why JPOX has it ;-)
> Anything that adds more information to the user domain and more clearly
> defines the object states is a good thing.
+1
>
> I agree with the principle of making the return an enum (for the "api21" jar -
> obviously can't be like that in the legacy jar since that has to support
> 1.3+). The only issue is that HOLLOW and P_NONTRANS have the same
> combinations of the various "isPersistent", "isTransactional", etc fields and
> that is why the JPOX method outputs "hollow / persistent-nontransactional"
Since we have always drawn a distinction, perhaps unwisely, between
hollow and PNT, we'll just have to follow that path.
David
| |
| Craig L Russell 2007-09-25, 7:11 pm |
| | |
| Craig L Russell 2007-09-25, 7:11 pm |
| | |
| Craig L Russell 2007-10-03, 7:11 pm |
| | |
|
|
|
|
| Joerg von Frantzius 2007-10-19, 1:12 pm |
| Wow! Is that really the site I used to know as apache's jdo site?!
Andy Jefferson schrieb:
> On 19 October 2007, David Ezzio (ys) wrote:
>
>
> http://db.apache.org/jdo/specifications.html
>
>
| |
| Craig L Russell 2007-10-19, 1:12 pm |
| | |
| Joerg von Frantzius 2007-10-19, 1:12 pm |
| Hi Craig,
I think that's worth some "Apache JDO site relaunched" story on
serverside, isn't it?
The site is really much better now, and one can quickly see what it's
all about (whereas before that was only understandable for spec addicts,
and that only after due studying the site).
Regards,
Jörg
Craig L Russell schrieb:
> Hi Joerg,
>
> Andy Jefferson has put in a ton of work to upgrade the site.
>
> Craig
>
> On Oct 19, 2007, at 7:38 AM, Joerg von Frantzius 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!
>
| |
| Michelle Caisse 2007-10-19, 1:12 pm |
| It would be nice if we could get the jdocentral.com redirect to
http://db.apache.org/jdo/jdocentral in place first. Does anyone have any
influence to get this to happen?
-- Michelle
Joerg von Frantzius wrote:
>Hi Craig,
>
>I think that's worth some "Apache JDO site relaunched" story on
>serverside, isn't it?
>The site is really much better now, and one can quickly see what it's
>all about (whereas before that was only understandable for spec addicts,
>and that only after due studying the site).
>
>Regards,
>Jörg
>
>Craig L Russell schrieb:
>
>
>
>
>
| |
| Robert Greene 2007-10-19, 1:12 pm |
| I think if we're going to put a story on the serverside, we ought to revisit
some of the content of the site. For example, "Why JDO" still refers to
J2EE Entity Beans, Toplink, Hibernate, etc. Perhaps it is time to update to
address JPA and put a statement in place about how JDO fits in with how
alternatives have evolved over the last 3 years.
Cheers,
-Robert
Robert Charles Greene
V.P. Product Strategy
Versant Corporation
255 Shoreline Dr #450
Redwood City, CA 94065
Office: (650)232-2431
Cell: (925)577-4634
-----Original Message-----
From: Michelle.Caisse@Sun.COM [mailto:Michelle.Caisse@Sun.COM]
Sent: Friday, October 19, 2007 8:49 AM
To: jdo-dev@db.apache.org
Cc: JDO Expert Group
Subject: Re: JDO 2.1 specification draft can be reviewed...
It would be nice if we could get the jdocentral.com redirect to
http://db.apache.org/jdo/jdocentral in place first. Does anyone have any
influence to get this to happen?
-- Michelle
Joerg von Frantzius wrote:
>Hi Craig,
>
>I think that's worth some "Apache JDO site relaunched" story on
>serverside, isn't it?
>The site is really much better now, and one can quickly see what it's
>all about (whereas before that was only understandable for spec addicts,
>and that only after due studying the site).
>
>Regards,
>Jörg
>
>Craig L Russell schrieb:
>
>
>
>
>
| |
| Robert Greene 2007-10-19, 1:12 pm |
| BTW - It's probably just a matter of rearranging and/or eliminating a few
things. For example, there is a lot of good content on JPA, there is just
also a lot of out dated stuff.
Robert Charles Greene
V.P. Product Strategy
Versant Corporation
255 Shoreline Dr #450
Redwood City, CA 94065
Office: (650)232-2431
Cell: (925)577-4634
-----Original Message-----
From: Robert Greene [mailto:rgreene@versant.com]
Sent: Friday, October 19, 2007 9:33 AM
To: Michelle.Caisse@Sun.COM; jdo-dev@db.apache.org
Cc: JDO Expert Group
Subject: RE: JDO 2.1 specification draft can be reviewed...
I think if we're going to put a story on the serverside, we ought to revisit
some of the content of the site. For example, "Why JDO" still refers to
J2EE Entity Beans, Toplink, Hibernate, etc. Perhaps it is time to update to
address JPA and put a statement in place about how JDO fits in with how
alternatives have evolved over the last 3 years.
Cheers,
-Robert
Robert Charles Greene
V.P. Product Strategy
Versant Corporation
255 Shoreline Dr #450
Redwood City, CA 94065
Office: (650)232-2431
Cell: (925)577-4634
-----Original Message-----
From: Michelle.Caisse@Sun.COM [mailto:Michelle.Caisse@Sun.COM]
Sent: Friday, October 19, 2007 8:49 AM
To: jdo-dev@db.apache.org
Cc: JDO Expert Group
Subject: Re: JDO 2.1 specification draft can be reviewed...
It would be nice if we could get the jdocentral.com redirect to
http://db.apache.org/jdo/jdocentral in place first. Does anyone have any
influence to get this to happen?
-- Michelle
Joerg von Frantzius wrote:
>Hi Craig,
>
>I think that's worth some "Apache JDO site relaunched" story on
>serverside, isn't it?
>The site is really much better now, and one can quickly see what it's
>all about (whereas before that was only understandable for spec addicts,
>and that only after due studying the site).
>
>Regards,
>Jörg
>
>Craig L Russell schrieb:
>
>
>
>
>
| |
| Christiaan 2007-10-24, 7:11 am |
|
Joerg von Frantzius-2 wrote:
>
> I think that's worth some "Apache JDO site relaunched" story on
> serverside, isn't it?
>
A promo talk in general on JDO 2 on the serverside would be a good idea if
you would ask me!
--
View this message in context: http://www.nabble.com/JDO-2.1-speci....html#a13381313
Sent from the JDO - Development mailing list archive at Nabble.com.
|
|
|
|
|