Hi Craig,
Before rushing off to create a TCK test for this use case, it
would be useful to create some language in the spec which the test
can verify.
According to section 18.15, "The embedded attribute applied to a
field of a persistence-capable type specifies that the
implementation will treat the field as a Second Class Object."
In section 6.3, the extensive discussion of SCO's leaves little
doubt that a perfectly acceptable implementation solution for what
to do when a SCO is evicted is to clear the FCO's referring field.
(It would be nice if the issue of evicting a SCO was discussed
when the evict methods are defined, but it is not.)
What is not clear is what should happen after an embedded PC
object is evicted. If the PC class is marked as embedded only,
then there is no reason for any of its objects to have a JDO
identity.
On the other hand, if the PC class is not marked embedded only,
then it sounds reasonable to me that the spec might require that
an object previously assigned to an embedded field should now
acquire a JDO identity. On the other hand, it also sounds
reasonable to me that it wouldn't. Instead, the spec might require
that the application call makePersistent on the now unreferenced
and previously embedded PC object.
At the present, the spec doesn't tell us what should happen, so
either behavior is allowed.
As always, my preference is that one rule be applied as widely as
possible for simplicity's sake. So therefore, I propose that we
consider only two possible rules: One, embedded and persistent PC
objects (whether the class is embedded-only or not) always become
transient when evicted, or two, all persistent PC objects when
evicted remain persistent, whether they are embedded or not. Neither
rule is clearly applied in the specification to the use case here.
Cheers,
David
Craig L Russell wrote:
If this isn't covered by a TCK test, perhaps it should be.
Any volunteers?
Craig
On Mar 27, 2009, at 9:42 AM, Michael Bouschen wrote:
Hi Christiaan,
I think the embedded instance is still persistent after the evict
call. It's life cycle state might change to hollow, but even then it
is still persistent. So isPersistent should return true for both calls.
Regards Michael
Hi,
suppose I have an embedded persistent object Address part of a
persistent
object Company. What should be printed for the following code
Address address = company.getAddress();
System.out.println("persistent: " + JDOHelper.isPersistent(address));
pm.evict(address);
System.out.println("persistent: " + JDOHelper.isPersistent(address));
kind regards,
Christiaan
--
*Michael Bouschen*
*Prokurist*
akquinet t...@spree GmbH
Bülowstr. 66, D-10783 Berlin
Fon: +49 30 235 520-33
Fax: +49 30 217 520-12
Email: [email protected]
Url: www.akquinet.de <http://www.akquinet.de>
akquinet t...@spree GmbH, Berlin
Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth
Amtsgericht Berlin-Charlottenburg HRB 86780 B
USt.-Id. Nr.: DE 225 964 680
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:[email protected]
P.S. A good JDO? O, Gasp!
