Re: Embedded object and evict

[Christiaan <ch...@hotmail.com>]

Craig, I think my main point is the confusion it causes. From the outside as
a developer you don't see whether a class is embedded or not (but you do
recognize system types). Also, the same class Address can be embedded in
some relations and not embedded in other relations. Like I said, my
reasoning for determining whether a class is embedded or not is not whether
I want them to behave like system types or not. It's is more on the
conceptual level, are they part of the object they belong to. 

I think the confusion is illustrated by the response I got on my original
question (what should isPersistent() return), which was a simple yes or no
question. In my opinion this should at least be given some attention in the
spec.



Craig L Russell wrote:
> 
> Hi Christiaan,
> 
> We have a defined major category of objects to deal with: first class  
> objects that are persistent, have an identity in the datastore, and  
> have an (elaborate) life cycle; second class objects whose values are  
> persistent but have no identity and have a much simpler life cycle.  
> Among the second class objects, we have user-defined classes,  
> implementation-defined classes that implement system interfaces,  
> mutable system classes, and immutable system classes.
> 
> I don't see the advantage of defining user-defined second class  
> objects as having different behavior from system classes.
> 
> In your use case, you have first class objects for which you want to  
> preserve the connection to the datastore but minimize the footprint.  
> At an application-specific time you want to restore the values from  
> the datastore. There is a life cycle for that: hollow.
> 
> You also want to restore the values of associated second class objects  
> independent of the owning first class objects. This is the part that I  
> don't understand. We don't allow restoring the value of second class  
> objects of system types (Date, Timestamp, Collection) so your  
> application needs to separate the handling of these objects from the  
> handling of first class objects.
> 
> So I'd like to see us more sharply define the boundary between first  
> and second class objects by treating second class objects as  
> transient. This would normalize the treatment of user-defined second  
> class objects to that of system-defined second class objects.
> 
> If you want to the other direction and define the behavior of second  
> class objects, please think about the life cycle of second class  
> objects and how they would respond to isDirty, isPersistent,  
> isTransactional, isNew, isDeleted, and isDetached. And how they  
> transition among life cycle states.
> 
> On May 29, 2009, at 3:43 AM, Christiaan wrote:
> 
>>
>> I think the problem is not when an embedded object has persistent  
>> behaviour,
>> but when it loses this behaviour. Currently this makes the behaviour  
>> of
>> embedded objects very different from "normal" persistent objects.
> 
> Right. It makes the behavior identical to other second class objects.
> 
>> When calling evictAll() or doing a commit (with retainValues=false)  
>> results a
>> normal persistent object still behaves the same as it did before the  
>> evict
>> or commit. Having a reference to an embedded object, this object  
>> suddenly
>> becomes a new transient instance:
>>
>> Address address = company.getAddress();
>> pm.evictAll()
>> pm.getCurrentTransaction().begin();
>> address.setZipCode("1234"); //would this work?
> 
> It would "work", but like date.setTime(), it would have no effect on  
> the persistent instance.
>>
>> pm.getCurrentTransaction().commit();
>>
>> So when specifying "that object only has persistent behavior when  
>> associated
>> with an owner" I think it is also important to specify when this  
>> association
>> is lost or not:
>> 1) if the association is lost (like it is now) The embedded object  
>> should
>> not nullify its fields but should contain the same information as it  
>> did
>> before the commit and evict.
> 
> The reason evict exists is to hollow out an instance and reduce its  
> footprint in the vm. This means to remove all outward pointing  
> references from the persistent instance. Then the garbage collector  
> can remove the instances (unless you defeat this by holding a strong  
> reference in the application).
> 
>> The above scenario would not work (nor does
>> state interrogation), an additional company.getAddress() is  
>> required. This
>> would work for the scenario which I mention where one thread is  
>> doing the
>> reads, and the other doing the evicts or commits. This is how it  
>> behaves
>> now, which is workable, but it is important to make the behaviour  
>> explicit.
> 
> This behavior is not specified. Since a long time ago,
> 
> <spec 6.3>
> SCO fields of persistence-capable types are identified as embedded.  
> The behavior of em-
> bedded persistence-capable types is intended to mirror the behavior of  
> system types, but
> this is not standard, and portable applications must not depend on  
> this behavior.
> </spec>
> 
> If we must standardize the behavior, I'm willing to do so but not by  
> defining a quasi-persistent user-defined second class object life  
> cycle. I think it's too late in the process to define a new category  
> of persistence.
>>
>> Also since the evictAll() makes the embedded object non-persistent,
>> explicitly mentioning that fields of the embedded objects are not  
>> nullified
>> would be good idea as well.
>>
>> 2) if the association is not lost fields can be nullified because in  
>> that
>> case the embedded object behaves the same as its owner. All mentioned
>> scerios would work since there would be no difference between normal  
>> and
>> embedded, only difference would be at database level.
> 
> I'm still not clear why you want this behavior for user-defined second  
> class objects and not objects like Date and Collection. Yes, you can  
> define the behavior of user-defined second class objects as different  
> from system-defined second class objects, but it's not trivial. And in  
> my opinion, not worth the cost.
> 
> Craig
>>
>>
>>
>>
>>
>> Craig L Russell wrote:
>>>
>>> I agree that embedded objects should be included in the spec. Right
>>> now, there are hints but no specified behavior for embedded objects
>>> with regard to the life cycle interrogatives and the behavior at
>>> commit and evict.
>>>
>>> I think the best approach is to treat embedded objects as transient
>>> for all of the life cycle interrogatives. Then there is no question
>>> about expected behavior after evict, commit, etc.
>>>
>>> This does impact design. If you choose to make an embedded object,
>>> then that object only has persistent behavior when associated with an
>>> owner. It's never dirty, and can't be the parameter of any of the  
>>> life
>>> cycle changing APIs.
>>>
>>> Craig
>>>
>>> On May 26, 2009, at 3:14 AM, Christiaan wrote:
>>>
>>>>
>>>> Does this need to be addressed in the spec? Personally I feel that
>>>> this
>>>> technical design issue really impacts the decision of a designer
>>>> whether a
>>>> class should be embedded or not, whereas I think it should be a
>>>> conceptual
>>>> decision whether a class should be embedded or not. So making it  
>>>> more
>>>> explicit in the spec would at least be one thing to do.
>>>> -- 
>>>> View this message in context:
>>>> http://www.nabble.com/Embedded-object-and-evict-tp22738918p23720315.html
>>>> Sent from the JDO - Development mailing list archive at Nabble.com.
>>>>
>>>
>>> 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!
>>>
>>>
>>>
>>>
>>
>> -- 
>> View this message in context:
>> http://www.nabble.com/Embedded-object-and-evict-tp22738918p23777771.html
>> Sent from the JDO - Development mailing list archive at Nabble.com.
>>
> 
> 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!
> 
> 
>  
> 

-- 
View this message in context: http://www.nabble.com/Embedded-object-and-evict-tp22738918p23919652.html
Sent from the JDO - Development mailing list archive at Nabble.com.