Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Downsides to bi-directional references?
Downsides to bi-directional references? [message #1832106] Wed, 09 September 2020 06:47 Go to next message
Hans van der Laan is currently offline Hans van der LaanFriend
Messages: 34
Registered: February 2020
Member
Having bi-directional relations in models often makes model traversal much easier. I can understand how from a modeling standpoint, you may want to have regular references instead of bi-directional references. However I was wondering, are there any downsides regarding performance why one should not just make all references bi-directional references?

[Updated on: Wed, 09 September 2020 06:47]

Report message to a moderator

Re: Downsides to bi-directional references? [message #1832125 is a reply to message #1832106] Wed, 09 September 2020 14:04 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31840
Registered: July 2009
Senior Member
The downside of a bidirectional reference isn't directly so much a performance concern but rather a persistent/serialization concern. In general both ends need to be serialized i.e., both must be non-transient, except if the references are not proxy resolving, i.e., if they can't cross resource boundaries, then one end can be transient. So take for example, a "super type" reference. However convenient it might be to make it bi-directional so you can know easily all the sub-types, having the super type instance serialize all sub-types is just generally not sensible/possible.

Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Downsides to bi-directional references? [message #1832152 is a reply to message #1832125] Thu, 10 September 2020 08:36 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7099
Registered: July 2009
Senior Member
Hi

As Ed highlights, bidirectionals between resources can be challenging. Suppose you have developed A.xmi and B.xmi with mutual references, now start editing C.xmi with references to A.xmi. How does the original A+B session feel about this? It seems that A+B+C must be treated as a load/save singleton.

However within a Resource, ask the converse question. What is the downside of not using a bi-directional reference when your algorithms need one? You risk developing flaky bodge code . Use the quality EMF implementation.

In OCL, all references are bi-directional, so the OCL run-time support for Ecore is obliged to support the opposite direction even though EMF doesn't. This incurs costs but provides flexibility and avoids the persistence difficulties. You might find a similar approach appropriate.

Regards

Ed Willink
Re: Downsides to bi-directional references? [message #1832185 is a reply to message #1832152] Fri, 11 September 2020 07:04 Go to previous message
Hans van der Laan is currently offline Hans van der LaanFriend
Messages: 34
Registered: February 2020
Member
Hi Ed&Ed,

Thanks for the replies! The trade-off is now much clearer.

Kind regards,

Hans
Previous Topic:Dependency graph between resources in a resourceSet
Next Topic:Updating ecore resource slows down build process
Goto Forum:
  


Current Time: Tue Apr 20 06:58:29 GMT 2021

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

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

Back to the top