Community
Participate
Working Groups
EMF 2.6.1. If EMF is exploited so that a reference is unidirectional when persisted but bidirectional at run-time by declaring the run-time-only EReference as transient and non-resolving, the following validation error results: "The opposite of a transient reference must transient if it is proxy resolving" [presumably a missing "be". and "it" is a little ambiguous] genmodel produces reasonable code which works as expected. The usage scenario seems reasonable, so is this just an over-enthusiastic validation. Repro below: <?xml version="1.0" encoding="UTF-8"?> <ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="p" nsURI="p" nsPrefix="p"> <eClassifiers xsi:type="ecore:EClass" name="c"> <eStructuralFeatures xsi:type="ecore:EReference" name="super" upperBound="-1" eType="#//c" eOpposite="#//c/sub"/> <eStructuralFeatures xsi:type="ecore:EReference" name="sub" upperBound="-1" eType="#//c" transient="true" resolveProxies="false" eOpposite="#//c/super"/> </eClassifiers> </ecore:EPackage>
This constraint isn't there accidentally. Proxy resolution operates only at one end at a time, so if you have a proxy at one end and you resolve it, the opposite will never point back unless it too has a proxy, which won't be the case if it's transient or doesn't resolve proxies. I'll use this bug to fix the typo though.
OK. The validation warns about a real problem, but is the use case unreasonable/useful? I'm using it to avoid the need to wind up the equivalent of ESuperAdapter or EcoreUtil.CrossReferencer. Perhaps genmodel just needs to instantiate a EObjectWithInverseAsymmetricResolvingEList.ManyInverse rather than a EObjectWithInverseResolvingEList.ManyInverse in which the new list overrides didSet to maintain the inverse proxy.
I'm sure we can have a very long discussion about what's reasonable and useful... One that unfortunately is never likely to reach a resolution. You'll note that we never modeled EClass.eSuperAdapter to have an inverse, nor did we design the framework to support populating an inverse purely via proxy resolution. We did that because it seems like a bad idea. An object's reflectively visible state could change simply be "read accessing" some other apparently unrelated object. For example, one might traverse a graph of objects, populating a cross referencer say, only to find that you need to do it twice, because relationships not populated during the first pass end up being populated purely as a side effect of traversing other objects. Good luck getting a cross referencer to work well with that design. Also, such updates look like actual modifications, i.e., ADD/SET notifications, not RESOLVE notifications, so a change recorder will be confused. Simply put, I don't want to go down that path. Even if the path seems reasonable or useful, it's a dark path because of the new problems it introduces to the framework as a whole.
The fixes are available in a published build.
Try again to resolve as fixed (and available in a build).
Oh, I guess I have to close them!
