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

Hi Blaise,

 

If the behavior you describe is acceptable, then we can 
close this issue with no action.  The current wording is that change 
summary represents a diff between the old state and the new state, with created 
objects being objects that have entered the scope, and deleted objects being 
objects that left the scope.  What calls were used to achieve this doesn't 
enter into the equation.  By the way, do you agree with this definition of 
"create" and "delete"?  This is also something that is being discussed in 
the calls.

 

I think there is a general feeling in the group that this 
behaviour will be surprising to users.  Although the spec doesn't really 
say so, simply by calling a method named "delete" (as opposed to, 
say, "detach"), I think the user has signified an intention, namely, that 
he wishes the object be deleted from the data store.  And the 
worry is, that representing a delete/ reattach as a move, we are losing this 
intention.

 

The 
problem with the sentence you quote is that it doesn't say how this scenario is 
represented in the change summary, and I'm worried that users will expect it be 
represented as a delete and a create.  Perhaps the most backwards 
compatible way to  go is simply to clarify this in the spec.  Perhaps 
we should simply remove the sentence, that is, unless someone comes up with a 
use-case why the user would want to re-attach a deleted object.  We 
can leave the behaviour implementation dependent.  We all agree that most 
users don't reattach deleted objects.  And if the object is not 
reused, we already have the correct behavior: the object appears as deleted in 
the change summary.  If the user does a re-attach, he's on his 
own.

 

Ron

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

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

Hi Ron,

I'm still on leave, but these darn new phones make it too hard to leave 
work behind entirely.

If I delete an object, and then re-add it, as a user I would be surprised 
to get an error.  This use case is not nonsensical but it would be done 
rarely.

The 
spec is clear on this point, not sure why we would add in weasel words.  Is 
there a use case this line is preventing? 

-Blaise

On 2009-09-17, at 9:51 AM, "Barack, Ron" <> wrote:

  

  
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