| Summary: | Detach-reattach of dirty object discards pre-detach featureDeltas | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Caspar D. <caspar_d> | ||||||
| Component: | cdo.core | Assignee: | Caspar D. <caspar_d> | ||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | saulius.tvarijonas, stepper | ||||||
| Version: | 3.0 | Flags: | stepper:
review+
|
||||||
| Target Milestone: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Caspar D.
Created attachment 174723 [details] Patch *** Patch adopted from bug 319836 *** (Modified to avoid API breakage.) Created attachment 174727 [details]
Patch v2 - ready to be committed
I mostly added some instanceof CDOTransactionImpl checks.
Yes, I see. But I have my doubts about those.
Consider this for example, from CDOStateMachine.java, lines
207-215:
if (transaction instanceof CDOTransactionImpl &&
((CDOTransactionImpl)transaction).getFormerRevisionKeys().containsKey(object))
{
reattachObject(object, transaction);
}
else
{
attachObject(object);
}
In your version, the condition that the transaction be an
instance of CDOTransactionImpl, affects the decision whether
to reattach or attach. This changes the meaning of the
'else' branch. That is, the else branch gets executed not
only for the case that the revisionKey is not found, but
also for the case the tx isn't a CDOTransactionImpl. In the
latter case, we are inadvertently covering up an error
state.
I prefer my original code, which will cause an exception...
My idea was that reattach can not be supported at all if the tx is not a CDOTransactionImpl. But it's well possible that other places must be touched for this, too. An exception is also okay for me. Do you want to change it? No review needed... Committed to R3_0_maintenance Moving all open problem reports to 4.0 Undoing accidental version change. Closing. |