Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 350447

Summary: Return value of eContainingFeature from CDORevision seems incorrect
Product: [Modeling] EMF Reporter: kaab <kaabab>
Component: cdo.coreAssignee: Eike Stepper <stepper>
Status: CLOSED WORKSFORME QA Contact: Eike Stepper <stepper>
Severity: normal    
Priority: P3    
Version: 4.1   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Whiteboard:
Attachments:
Description Flags
Unit Test showing the assertion failure
none
Ecore Model Used in test to reproduce the issue
none
test v2 none

Description kaab CLA 2011-06-27 09:49:17 EDT 
Build Identifier:  I20110613-1736

+ This was first reported in the forum : http://www.eclipse.org/forums/index.php/m/687581/#msg_687581

+ The issue is that the return value here is different from the expected return value (codeElement) as asserted by the test case.

+ This was tested using CDO 4.0

Reproducible: Always

Steps to Reproduce:
1. Download latest eclipse build (3.7)
2. Install EMF and CDO SDK from (latest from indigo update site)
3. Setup a project where the ecore model attached code could be generated (kdm-1.0.ecore), generate model code
4. Setup and run the unit test provided with the bug report
5. The unit test asserts that the feature retrieved using eContainingFeature is the same when retrieved from the EObject and from the CDO Revision, here the test fails with Comparison failure :
org.junit.ComparisonFailure: expected:<[codeElement]> but was:<[module]>.
Given the definition provided by Eike in the previous forum entry, my understanding is that this test should pass.
Comment 1 kaab CLA 2011-06-27 09:49:55 EDT 
Created attachment 198648 [details]
Unit Test showing the assertion failure
Comment 2 kaab CLA 2011-06-27 09:50:31 EDT 
Created attachment 198649 [details]
Ecore Model Used in test to reproduce the issue
Comment 3 Eike Stepper CLA 2011-07-03 06:32:52 EDT 
After a while I was able to run your test and reproduce your failure. This failure is caused by wrong usage of the containingFeatureId. The correct interpretation can be found in BasicEObjectImpl.eContainingFeature() and I've rewritten your code to:

    EStructuralFeature feature = containingFeatureId <= InternalEObject.EOPPOSITE_FEATURE_BASE ?
        container.getEClass().getEStructuralFeature(InternalEObject.EOPPOSITE_FEATURE_BASE - containingFeatureId) :
        ((EReference)revision.getEClass().getEStructuralFeature(containingFeatureId)).getEOpposite();

With this code the test passes. If you want to know why exactly EMF stores/interprets this value in this particular way you may want to ask Ed (either cc him here or ask in the newsgroup).
Comment 4 Eike Stepper CLA 2011-07-03 06:34:26 EDT 
Created attachment 199007 [details]
test v2

This is a passing version that also has some other enhancements that you may want to study by comparing to your original version.
Comment 5 kaab CLA 2011-07-04 10:44:59 EDT 
It seems close to what I suspected but did not go trough the code in BasicEObjectImpl, which clarifies things a lot. Thanks for reply and worthful comments.

Cheers,
Comment 6 Eike Stepper CLA 2011-07-04 13:13:08 EDT 
You're welcome.

I've also added respective JavaDoc to CDORevisionData.getContainingFeatureID() to make it harder to run into this trap in the future ;-)
Comment 7 Eike Stepper CLA 2012-09-21 07:17:05 EDT 
Closing.