AW: [sdo] ISSUE 165: Define behavior of DataObject.delete wrtChangeSummary

Hi Blaise,

 

First off, welcome back, and best wishes on your 
"blessed event".

 

There's no doubt that the 2.1 spec allows, even encourages, 
deleted objects be reused in the graph. I just couldn't help but wonder 
why user would want to do such a thing.  Pooling was just 
a guess, because I can't think of anything else.  

 

The scenario you mention could also be handled with a 
detach.  The only difference is that with the delete, all non-readonly 
properties are reset.  If you're just moving something, that seems like an 
odd and confusing thing to do.  So why call delete?  If it's really 
desirable to reset the non-readonly properties too, then the user can of course 
do so himself.  But do you have a use-case for this?

 

My thinking is really to replace the statement you quote 
with something along that lines that it is a "user error" to reuse a deleted 
object, resulting in "undefined behavior".  This leaves implementations 
free to provide a backwards compatible option.  That maybe helps, but it 
doesn't change the fact that we are talking about breaking compatibility 
here.  On the other hand, 

1)  I believe the functionality is nonsencical, and 
very rarely used (though I have no evidence of this)

2)  We can offer users the ability to achieve the same 
result using other means.

 

Best Regards,
Ron

Von: Blaise Doughan 
[mailto:] 
Gesendet: Donnerstag, 17. 
September 2009 14:38
An: Barack, Ron
Cc: 

Betreff: Re: [sdo] ISSUE 165: Define behavior 
of DataObject.delete wrt ChangeSummary

Hi Ron,

Based on the following statement, I never interpreted 
this as a means of implementing a pool of DataObjects, rather I took it to mean 
that I can put this deleted object back in the graph and it is now a modified 
rather than a deleted object (it maintains its object identity).  In other 
words a deleted object is not a dead object.

"A deleted DataObject can be used again, have its values 
set, and again be added into the data graph."

If this statement was removed, does that mean we need to 
guard against deleted objects being put back in the graph?  Possibly 
throwing an exception, this would be a backwards compatibility 
issue.

-Blaise

Barack, Ron wrote: 

  
  
  
  
    
    
    
    

      RAISED BY: Ron 

ChangeSummary is defined as a diff between 
        the state of the graph when beginLogging was called, and the state when 
        endLogging was called. The API used to modify the graph does not enter 
        into the the definition. 

Users that call DataObject.delete 
        expect for the object to be represented in the change summary as a 
        deleted object. Usually, that is what they get. But the description of 
        the delete method seems to suggest that delete is rather more intended 
        for implementing a pool of DataObjects, that are freed and later re-used 
        in the graph. If delete is used in this way, it is possible that the 
        "deleted" object appears as a modified object in the change summary. 
        

PROPOSAL: 
The utility of implementing object pools is 
        questionable to say the least. It seems more reasonable to say that the 
        delete method is intended to indicate the object should be deleted...as 
        opposed to detach, which is a step towards moving the object. 
    

  
 

  
http://www.osoa.org/jira/browse/SDO-165