Hi Ron,
The behaviour I describe (which is already in the spec) is acceptable
and consistent with the definition on ChangeSummary.
I also agree with the spec definition of create & delete for the
following reasons:
- SDO is a data representation specification, not a persistence
specification. We have not specified how any behaviour relates to a
persistent store, it would be odd to only specify it for create/delete.
- Both detach & delete are represented in the ChangeSummary the
same way, are you saying that both result in a deletion from the data
store, or are you suggesting detach would be represented differently
(backwards compatibility issue)
- Changing the definition of ChangeSummary is a backwards
compatibility issue.
- This appears to be a large change considering I thought we were
trying to close down SDO 3.0. Similar discussions occurred in the DAS
group, ultimately without resolution. Are we considering delaying the
release of SDO 3.0?
I do not understand the argument that the behaviour is surprising to
users. First this has been the behaviour as long as I have been part
of SDO, so users are familiar with it. Second, the definition of
ChangeSummary is a change to the graph. If I add something to graph it
is created, if I remove something it is deleted, and if I put it back
in it is not deleted any more (it still maintains its object identity,
it is not a different object). Considering the spec does not talk
about data stores, it is unrealistic to have any data store related
expectations.
I do not see how this scenario could be represented as a
delete/create. The spec states that a DataObject can only be one of
created/modified/deleted. It would be another change to the spec
(backwards compatibility issue) to allow it to be in more than one
state.
I was surprised after you had started a thread to solve the move vs
create/delete issue once and for all stating that allowing both
behaviours made it difficult for data access services to interpret a
ChangeSummary, that now you are taking clear behaviour and opening it
up for implementation dependent behaviour.
-Blaise
Barack, Ron wrote:
1BC7B594EE497146B0CFF2F493B6823406C71D0501@DEWDFECCR02.wdf.sap.corp"
type="cite">
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
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
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
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:
1BC7B594EE497146B0CFF2F493B6823406C6D07382@DEWDFECCR02.wdf.sap.corp"
type="cite">
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. |
|