Eclipse Community Forums: EMF » Downsides to bi-directional references?

Help

Home

Home » Modeling » EMF » Downsides to bi-directional references?

Show: Today's Messages :: Show Polls :: Message Navigator

Downsides to bi-directional references? [message #1832106]

Wed, 09 September 2020 06:47

Hans van der Laan

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

Ed Merks

Messages: 33136
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/

Report message to a moderator

Re: Downsides to bi-directional references? [message #1832152 is a reply to message #1832125]

Thu, 10 September 2020 08:36

Ed Willink

Messages: 7655
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

Report message to a moderator