| (SOLVED) Cyclic resolution of lazy links problem [message #1173414] |
Wed, 06 November 2013 14:00  |
 Jens Rabe
Messages: 81
Registered: September 2013 |
Member |
|
|
Hello,
I've been struggling with this for a week now and cannot find a solution to the following problem:
I have two models. In the models, there are classes which reference another class from the other model in an 1-to-1 relationship, i.e.:
A.b single-references B, B.a single-references A, and A.b's opposite is B.a and vice-versa.
Now, A is serialized the standard XMI way which is desired as it only provides some internal functionality. The user always works on B. B is (de)serialized using an Xtext-based DSL.
My problem now is:
When saving B (myB.eResource().save()), and the serializer comes to B.a, it tries to resolve B.a, which in term tries to resolve A.b pointing to the B I currently want to serialize, causing the serialization to fail with "Cyclic resolution of lazy links".
How can I overcome this problem?
[Updated on: Thu, 07 November 2013 07:49] Report message to a moderator |
|
|
|
| Re: Cyclic resolution of lazy links problem [message #1174609 is a reply to message #1173554] |
Thu, 07 November 2013 07:49  |
Jens Rabe
Messages: 81
Registered: September 2013 |
Member |
|
|
I solved the problem and you were right. I got it wrong how the scoping actually works, plus, our model which existed before the creation of the DSL was not really prepared. I will explain it here in case other people might stumble upon a similar issue.
When my Scope_B_a method is called, the deserializer currently tries to deserialize B.a. Now, the scope was incorrectly constructed by calling myB.getA() before, but since the reference to "a" has not yet been resolved, this creates the cycle. The usual approach is to extend the DSL to explicitly specify the file to import and have "a" reference it later. Since this reference is of no interest for the user, moreover, it would be dangerous if he changed it, we have to adjust our model to hide it. Since A is internal, the user should never see and tinker with its source code and is even directly redirected to the B when he double-clicks the A file in the workbench. Our approach is now to make this reference derived and transient on both sides, remove the rule from the grammar and put a hidden uni-directional reference from A to B in A. Whan A.b is accessed, it is delegated to the hidden reference, and when B.a is called, the platform figures out which A to use and loads it if needed.
|
|
|
Powered by
FUDForum. Page generated in 0.03575 seconds
] 
Search
Help
Register
Login
Home
