Skip to main content



      Home
Home » Modeling » EMF » Downsides to bi-directional references?
Downsides to bi-directional references? [message #1832106] Wed, 09 September 2020 02:47 Go to next message
Eclipse UserFriend
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 02:47] by Moderator

Re: Downsides to bi-directional references? [message #1832125 is a reply to message #1832106] Wed, 09 September 2020 10:04 Go to previous messageGo to next message
Eclipse UserFriend
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.
Re: Downsides to bi-directional references? [message #1832152 is a reply to message #1832125] Thu, 10 September 2020 04:36 Go to previous messageGo to next message
Eclipse UserFriend
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 03:04 Go to previous message
Eclipse UserFriend
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: Sun Jul 13 00:53:48 EDT 2025

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

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

Back to the top