EMF Adventures Part 3: Object Identity
This is a third post about my adventures in EMF. You can find the other two here and here respectively.
Today's post is about object identity in EMF. I ran into this problem, while trying do build a structural comparator for EMF M1 models.
The meta model for today' experiment is shown below:
The content of the meta model is rather simple. A Machine consists of Parts, and there is a Purchase Order, which can refer to particular Parts.
The interesting thing about this setup is, how the links between PurchaseOrder and Part are persisted. To explore this, let's generate the code for model editors (the ugly tree based ones.. maybe I'll come up with some nice things later). After running the editor, we create to XMI files: machine.emfid and po.emfid. The first one contains a Machine and two Parts, the second one contains a PurchaseOrder, referring to the two Parts of the Machine.
The XMI for this setup looks as follows:
<emfid:Machine
xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:emfid="http://gruschko.org/test/emfid">
<parts name="part1"/>
<parts name="part2"/>
</emfid:Machine>
<emfid:PurchaseOrder
xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:emfid="http://gruschko.org/test/emfid">
<parts href="machine.emfid#//@parts.0"/>
<parts href="machine.emfid#//@parts.1"/>
</emfid:PurchaseOrder>
As can be seen in the second XMI snippet, the Parts are being referenced by their position in the list of machine's part. Now, let's see what happens, if a third Part is added to the Machine. To make matters more interesting, I will add the Part by hand, between part1 and part2.
This:
is the new model. Until now, everything looks fine. The only problem is, that the reference in the XMIResource, describing the PurchaseOrder has not changed.
The immediate impact of the problem, can be seen in the properties view of the editor. Before I introduced the "part 1.5" Part, the view showed the following picture:
After part 1.5 addition, the picture changed to:
The problem, posed by this behavior, is quite obvious. A link set changed, although the user has not done anything active, to actually change it. The implications are rather dramatic. This behavior means, for example, that all references to distributed resources will become invalid, as soon as the referred resources are being changed.
But wait, there is a solution to this worry. At least in the MOF world, there are unique identifiers for each object, called MOF IDs. A quick search of the EMF API revealed, that indeed there is a possibility to create unique IDs on model elements. The problem is, that it only works on XMLResource and has to be set by hand. This isn't the solution I wanted, because there is not always any code, to put the ID setter into.
Another solution altogether, is the possibility, to set the ID attribute of the eAttribute Ecore class to true, on name attribute of the Part class. The problem of this approach is obviously, that someone has to guarantee the uniqueness of the IDs. But let's first try, if this approach brings the desired effect. Namely, that the changes of the referred resources stop invalidating distributed link sets.
Now, the XMI of PurchaseOrder looks as follows:
<emfid:PurchaseOrder
xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:emfid="http://gruschko.org/test/emfid">
<parts href="machine.emfid#part1"/>
<parts href="machine.emfid#part2"/>
</emfid:PurchaseOrder>
As can be seen, the references do not use the position in the referred resource, but the value of the ID attribute is utilized as reference. The problem with this approach (besides of the mentioned uniqueness problem) is, that a "visible" attribute is being used as a key. Two different objects can very well be intended, to have two equal sets of attributes. In the next installment of "EMF Adventures", I may provide some examples of equal ID attributes and EMF's behavior in face of this situation.