Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » (SOLVED) Cyclic resolution of lazy links problem
(SOLVED) Cyclic resolution of lazy links problem [message #1173414] Wed, 06 November 2013 14:00 Go to next message
Jens Rabe is currently offline Jens RabeFriend
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 #1173554 is a reply to message #1173414] Wed, 06 November 2013 15:54 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 13488
Registered: July 2009
Senior Member
Hmm how does your scoping / indexing look like?
seems you rely on resolved links there


Need professional support for Xtext, Xpand, EMF?
Go to: https://www.itemis.com/en/xtext/
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Cyclic resolution of lazy links problem [message #1174609 is a reply to message #1173554] Thu, 07 November 2013 07:49 Go to previous message
Jens Rabe is currently offline Jens RabeFriend
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.
Previous Topic:Issue with cross-referencing elements of other EMF model
Next Topic:[ContentAssistant] Propose type involving ImportManager
Goto Forum:
  


Current Time: Fri Jul 03 20:27:37 GMT 2020

Powered by FUDForum. Page generated in 0.01390 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top