Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [Xcore] Reference properties are always unique in Ecore derived from Xcore
[Xcore] Reference properties are always unique in Ecore derived from Xcore [message #1787650] Wed, 30 May 2018 12:50 Go to next message
Denis Nikiforov is currently offline Denis NikiforovFriend
Messages: 200
Registered: August 2013
Senior Member
Hi

Here is a simple Xcore model:
package test

class ClassA {
    contains ClassB children
}

class ClassB { }


I open this model with "Reflective Xcore Model Editor" and I see 3 packages: XPackage, GenModelPackage, EPackage.

The children property is non-unique in XPackage as expected (see left part of attached picture). But this property is unique in the derived EPackage (see right part of attached picture). Why it's marked as unique?
Re: [Xcore] Reference properties are always unique in Ecore derived from Xcore [message #1787803 is a reply to message #1787650] Wed, 30 May 2018 14:10 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 29653
Registered: July 2009
Senior Member
All EReferences are treated as unique. That's certainly necessary for containment and bidirectional references, though not strictly necessary for one-way cross references: https://bugs.eclipse.org/bugs/show_bug.cgi?id=89325
Re: [Xcore] Reference properties are always unique in Ecore derived from Xcore [message #1789873 is a reply to message #1787803] Thu, 31 May 2018 08:25 Go to previous messageGo to next message
Denis Nikiforov is currently offline Denis NikiforovFriend
Messages: 200
Registered: August 2013
Senior Member
The problem is that an Xcore model and an derived Ecore model are inconsistent. I have an Xtend-based code generator. When I generate code for an XPackage everithing works as expected. But when I execute a similar codegenerator for EPackage contained in the same resource (and derived from the XPackage) all references becomes unique. I think references must be unique or non unique in both XPackage and EPackage.

Oh, I've found a workaround: https://bugs.eclipse.org/bugs/show_bug.cgi?id=467855
@Ecore(^unique="false")

But if I can mark a reference as non-unique using the annotation, why it can't be marked automatically?..
Re: [Xcore] Reference properties are always unique in Ecore derived from Xcore [message #1789879 is a reply to message #1789873] Thu, 31 May 2018 10:15 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 29653
Registered: July 2009
Senior Member
The Xcore model is not intended to be something from which you directly generate code. The GenModel in combination with the Ecore model is intended for that purpose. The Xcore model's only intended purpose is to represent the syntax from which to derive a GenModel and an Ecore model. Given that EMF's generator doesn't support generating non-unique references nor is this supported for dynamic EMF models, it's kind of irrelevant at which value this attribute has.
Re: [Xcore] Reference properties are always unique in Ecore derived from Xcore [message #1789883 is a reply to message #1789879] Thu, 31 May 2018 10:52 Go to previous messageGo to next message
Denis Nikiforov is currently offline Denis NikiforovFriend
Messages: 200
Registered: August 2013
Senior Member
I agree, code generation from an Xcore model was really painful. EMF's generator doesn't support non-unique references, but I write my own generator. And I guess there could exists a number of alternative code generators, which use Ecore models as an input.
Re: [Xcore] Reference properties are always unique in Ecore derived from Xcore [message #1789888 is a reply to message #1789883] Thu, 31 May 2018 11:32 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6111
Registered: July 2009
Senior Member
Hi

In any non-trivial model there will almost inevitably be some redundant state such as whether a [1..1] multiplicity element is ordered and/or unique. UML and Ecore are identical with respect to this redundancy although different with respect to the corresponding defaults.

Arguably it would change the surprise into a bug if EMF imposed a fixed value on the redundant state, either silently, or through validation warnings. But the consequent non-equality of functionally identical models is unfortunate.

For my testing purposes, I have taken to introducing a pre-normalization that folds all redundant state to deterministic values before comparing models for equality.

(The accidental ordering of non-ordered collections is another irrelevance that normalization can eliminate.)

Regards

Ed Willink



Re: [Xcore] Reference properties are always unique in Ecore derived from Xcore [message #1789942 is a reply to message #1789888] Fri, 01 June 2018 06:20 Go to previous messageGo to next message
Denis Nikiforov is currently offline Denis NikiforovFriend
Messages: 200
Registered: August 2013
Senior Member
Oh, I've got it.

@Ecore(^unique="false") works only for single-valued references. For multi-valued reference one will get the following error: "A containment or bidirectional reference must be unique if its upper bound is different from 1"

Xcore models aren't equivalent to Ecore models! Ecore models doesn't support non-unique multi-valued references. But Xcore models support them:
package test

class ClassA {
    contains ClassB[] nonUniqueChildren
    contains unique ClassB[] uniqueChildren
}

class ClassB { }

What is a purpose of 'unique' keyword in Xcore? Should it be used only for multi-valued attributes (and not for references)? Or it can be used for multi-valued references as well? And Ecore must also support them?

Prohibition of non-unique multi-valued references complicates a little bit usage of Ecore as a modeling language for custom code generators... I think Ecore should be a more generic modeling language and it shouldn't be so highly coupled with EMF code generator.
Re: [Xcore] Reference properties are always unique in Ecore derived from Xcore [message #1789947 is a reply to message #1789942] Fri, 01 June 2018 06:57 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 29653
Registered: July 2009
Senior Member
I prefer not to go in circles on this subject. I've already pointed you at https://bugs.eclipse.org/bugs/show_bug.cgi?id=89325 which hightlights the fact that in no case is a non-unique EReference supported, i.e., not in the generator, not at runtime (even for dynamic models), and not in any of the downstream frameworks which assume uniqueness. Have you looked at this?

So at this point, the value of the unique feature on an EReference is actually kind of pointless, and as you note, the unique keyword on an XReference is also pointless. It's only really meaningfully implemented and supported for EAttributes and even there it's pointless unless the upper bound is > 1.

Ecore is intended to support its own runtime and the generator is designed to support this runtime as well. If you want to use Ecore for some other purpose (that doesn't use the EMF runtime) you can of course add your own arbitrary annotations (XAnnotations that map to EAnnotations) to capture any additional/different information you need/want in order to generate something unrelated to EMF/Ecore. Best you not expect Ecore to change at this point in its long life to conform to some other ideal that you might imagine...
Previous Topic:MDA
Next Topic:[XCore] .xcore header comments parsing problem
Goto Forum:
  


Current Time: Sat Nov 17 11:01:23 GMT 2018

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

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

Back to the top