| [CDO] Updates to model objects creates new table entry instead of incrementing the revision? [message #1841310] |
Tue, 11 May 2021 21:38  |
 Warwick Burrows
Messages: 132
Registered: July 2009
Location: Austin, TX |
Senior Member |
|
|
As shown in the screen capture that I've attached I'm seeing cases where an update to a model object in CDO isn't creating another table entry for that CDOID with a new revision - instead it creates a table entry with a new cdo_id for the object and sets the revision to 1 again. . You can see the cdo_resource is 53063 and the first entry for the resource in the table is 53073. My application relies on the cdo_id not changing from 53073 and instead for the cdo_version to be incremented for each update. The latest revision is indicated by the cdo_revision column being 0. So my application now loses track of the latest revision for my CDO object with ID 53073 and its revision history because of the CDOID change. For many years using CDO 4.1 I've been using this mechanism and just recently noticed the change. Maybe I haven't enabled a feature of CDO 4.12 revision control that was previously the default behavior for 4.1? Does anyone recognize this behavior for updates and have a suggestion how to fix it?
Edit: I've also uploaded a screen cap of an entry in the object model table showing the expected behavior. This is for the same combo of my app version and CDO 4.12 version as the misbehaving object from the first screen cap.
[Updated on: Tue, 11 May 2021 22:05] Report message to a moderator |
|
|
|
|
| Re: [CDO] Updates to model objects creates new table entry instead of incrementing the revision? [message #1841390 is a reply to message #1841346] |
Fri, 14 May 2021 06:09  |
|
There's no intented change in CDO's general versioning behavior. Here are a few thoughts that might help you detect the cause of the problem:
- New objects must be created on the client side (just like all model modifications). The server just reacts.
- The actual creation of new objects always happens outside of CDO's control, i.e., in an EMF factory method. If such a new object is added to a CDO-controlled model we call that "attachment".
- Similar but different is a "reattachment". This happens when the object-to-be-attached had been attached before, but then (temporarily) detached. Reattachment is detected with the help of the CDOTransactionImpl.cleanRevisions map. This map is cleared at the end of a commit() or rollback() operation!!!. After these operations an attach of previously detached objects creates proper new objects (with new IDs). This is the only mechanism that I know, which could create the observed results. For example, drag and drop of objects in the UI creates detach/reattach transition pairs. Combined with a handler somewhere (e.g., a CDOTransactionHandler) that causes cross-cutting commits you could sporadically observe the reported behavior.
- If you want to set a breakpoint the earliest point is probably CDOStateMachine.attach(). In CDOStateMachine you can even distinguish between a normal "attach" and a "reattach".
- If debugging is not possible you could also add a tracing CDOTransactionHandler.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
Powered by
FUDForum. Page generated in 0.01846 seconds
] 
Search
Help
Register
Login
Home
