Hi Craig,
+1
Regards Michael
Javadogs,
I'll hold this vote open until January 2.
[ ] Adopt the proposal below.
<proposed 15.3>
If two relationships (one on each side of an association) are mapped
to the same column, the field on only one side of the association
needs to be explicitly mapped.
The field on the other side of the relationship can be mapped by using
the mapped-by attribute identifying the field on the side that defines
the mapping. Regardless of which side changes the relationship, flush
(whether done as part of commit or explicitly by the user) will modify
the datastore to reflect the change and will update the memory model
for consistency. There is no further behavior implied by having both
sides of the relationship map to the same database column(s). In
particular, making a change to one side of the relationship does not
imply any runtime behavior by the JDO implementation to change the
other side of the relationship in memory prior to flush, and there is
no requirement to load fields affected by the change if they are not
already loaded. This implies that if the RetainValues flag or
DetachAllOnCommit is set to true, and the relationship field is
loaded, then the implementation will change the field on the other
side so it is visible after transaction completion.
Conflicting changes to relationships cause a JDOUserException to be
thrown at flush time. Conflicting changes include:
adding a related instance with a single-valued mapped-by relationship
field to more than one one-to-many collection relationship
setting both sides of a one-to-one relationship such that they do not
refer to each other
</proposed 15.3>
On Dec 21, 2005, at 11:23 AM, Craig L Russell wrote:
Hi David,
Thanks for your comments.
The "in your face" issue I'm wrestling with is the inconsistency in
the specification where we say that changes are ignored if made to the
"mapped-by" side and also that changes made to the memory model are
visible after commit. So I took a fresh look at the requirements and
practical aspects of implementation.
JDO 1.0 requires byte-code enhancement. JDO 2.0 now admits
implementations that don't use byte-code enhancement, weaving, or
aspects in order to intercept domain model changes during a
transaction. Synchronizing the memory model with the database is now
deferred to flush (which might happen during commit). At flush time,
the JDO implementation gets control (possibly for the first time after
loading the instances) and can do whatever the spec requires. It's
evident to me that it's possible to detect changes to either side of
the relationship and make the two sides consistent.
The proposal is carefully worded to not require that the
implementation do extra work in case the memory model is not fully
instantiated. In particular, it's possible to add a hollow Employee to
a Department.emps collection without instantiating the Employee
instance. Similarly, it's possible to set the Employee.dept field to a
hollow Department without instantiating the Department instance.
The original wording in the JDO 2.0 spec was informed by the work in
EJB3 which derived from TopLink and Hibernate implementations that
don't worry much about the "mapped-by" side of the relationship. But I
don't think that it makes sense for JDO that users' model changes to
be ignored just because they happen to be made to the "wrong side" of
the relationship.
This proposal is where I ended up.
1. JDO implementations get control at flush;
2. User changes should not be ignored;
3. Inconsistencies should not be accepted, as they indicate user code
gone bad.
I agree it's a tradeoff. I'd like to see managed relationships in
memory but given the constraints I don't see it happening for JDO 2.
And I'd really like to see managed relationships be a separate issue
addressed in another JSR. It's not just a persistence issue; it's not
a mapping issue; it's a domain model issue.
Regards,
Craig
Slightly updated for clarity:
On Dec 21, 2005, at 3:52 AM, David Bullock wrote:
Bin Sun wrote:
Think that without managed relation, if I modify one side and
commit, I can't see the other side changed accordingly. But If I
restart the JDO engine (such as restarting the web-server), I can
see the change then, since it uses the same column referred by
'mapped by'. So, without any JDO operation, we'll see different
result at different time (before and after restarting), this becomes
a real consistency
problem.
As the spec and the proposal stands, you still have a consistency
problem before and after commit. I'm interested to hear why the
consistency issue only matters between server restarts, but not
between before- and after- commit.
cheers,
David.
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
--
Michael Bouschen [EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED] http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
