db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Ezzio <da...@ezzio.us>
Subject Re: Embedded object and evict
Date Mon, 30 Mar 2009 17:19:54 GMT
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 tech@spree GmbH
>> Bülowstr. 66, D-10783 Berlin
>>
>> Fon:   +49 30 235 520-33
>> Fax:   +49 30 217 520-12
>> Email: michael.bouschen@akquinet.de
>> Url:    www.akquinet.de <http://www.akquinet.de>
>>
>> akquinet tech@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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
> 

Mime
View raw message