[ Post a follow-up to this message ]

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!
>

[ Post a follow-up to this message ]

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:
> 
>

[ Post a follow-up to this message ]

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!
>

[ Post a follow-up to this message ]

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
>
> 
>

[ Post a follow-up to this message ]

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!
>

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

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!
>

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]