Home » Modeling » EMF » [CDO] Container reference db mapping- referential integrity problem
| [CDO] Container reference db mapping- referential integrity problem [message #1844830] |
Mon, 27 September 2021 13:00  |
 Erik Lundström
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Hello,
One of my customers have encountered referential integrity problems with CDO data in production. During resarch of the problem, I have found the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=491859, which I believe to describe what we are facing.
As part of my investigation, I have been running the JUnit test for above mentioned bug, i.e. "Bugzilla_491859_Test.java". This test makes use of the "base" meta model, as defined in "org.eclipse.emf.cdo.tests". The interesting bit as far as I am concerned is the modelled EReference "parent" on the EClass "Element". For an attached object, I believe the value of the "parent" should be the same as the value of eContainer(), if the object is contained in the opposite containment reference (Element.subelements, in the case of Element.parent).
In this test, this litle object model is created and committed:
// document
// document/root
// document/root/element
// document/root/element/child1
// document/root/element/child2
After the initial commit, two replacements - "replace root->root_new, replace element->element_new" - are made and committed.
If running the test as part of the "AllTestsDBH2Audit" and inspecting the h2 database table "REPO1.BASE_ELEMENT" at the end of the test, I note the following for the "child1" element (the same goes for "child2") :
- Version 1: The "container" value is set (to CDO_ID=6). The "parent" is not set (remains "null").
- Version 2: The "parent" is now set to the same value as "container" (to CDO_ID=6).
- Version 3: The "container" has changed (to CDO_ID=10), but "parent" wrongly still refers to element (CDO_ID=6). That is deleted/detached by now!
This leaves me confused on how CDO manages the db mapping of EMF container reference values. Shouldn't "parent" have the same value as "cdo_container" in all three versions described above? (Please also see the attached screenshot of the h2 db table for more clarity).
Finally, I can also reproduce the described failure if extending the test with the extra "replace" as suggested by Thorsten Schlathölter in comment # 7 here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=491859#c7
Also, if applying his gerrit change https://git.eclipse.org/r/c/cdo/cdo/+/76403/, the extended test will succeed.
|
|
| | |
| Re: [CDO] Container reference db mapping- referential integrity problem [message #1844936 is a reply to message #1844862] |
Thu, 30 September 2021 06:42  |
|
The navigable (modeled) container references really serve no critical purpose in the CDORevisions. EMF uses InternalSettingDelegateSingleContainer to access their values, i.e., it delegates to eContainer(), anyways. I believe that the respective slots in CDORevision.values could be eliminated (if not needed for debugging purposes). The respective columns in the DB could be useful for SQL queires, as the CDO_CONTAINER column is usually only helpful in combination with the rather hard-to-interpret CDO_FEATURE column. But then the values in these columns should be correct and complete.
My favorite solution is this:
1) Make the slots in CDORevision.values optional, and off by default.
2) Make the DB columns optional, and on by default. In this case we'd also have to ensure that their values are correct and complete.
3) Provide a DB migration that removes the existing columns, if not required.
4) Provide a DB migration that fixes possible incorrect values, if these columns are required for SQL queries.
You see, this is a lot of effort. And I wonder if this is absoluetely needed and who would want to fund it.
Regarding your problem with org.eclipse.emf.cdo.internal.server.TransactionCommitContext.checkXRefs() I doubt that it can be related to incorrect values in the navigable container columns. These features/columns should be skipped in org.eclipse.emf.cdo.internal.server.XRefsQueryHandler.collectSourceCandidates(EClass, EReference, Collection<EClass>, Map<EClass, List<EReference>>) :
if (eReference.isContainer())
{
return;
}
What do you think?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Container reference db mapping- referential integrity problem [message #1844946 is a reply to message #1844936] |
Thu, 30 September 2021 12:18 |
Erik Lundström
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Hi,
I agree, it seems to be a big effort to implement your "favorite solution".
After running (my application) with your fix, the results look positive. I am accessing data where there are problems, i.e. where there are bad values (IDs of deleted objects) for a column representing a modeled container reference in the DB. What is different with your fix applied is that I can now move and replace objects again, without experiencing DanglingIntegrityException. So from my point of view, my DB needs no fixing and can thus remain in the state it is, which is good.
I am not so sure what to respond to that question of yours however, except that yes I agree, navigable/modeled references are excluded there :)
Thanks again
Erik
|
|
|
Goto Forum:
Current Time: Fri Apr 19 13:41:50 GMT 2024
Powered by FUDForum. Page generated in 0.02471 seconds |
] 
Search
Help
Register
Login
Home
