Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » New EClass instance validation
New EClass instance validation [message #1374408] Thu, 22 May 2014 12:20 Go to next message
Mauro Condarelli is currently offline Mauro Condarelli
Messages: 417
Registered: September 2009
Senior Member
Hi, is there some automagic way to ensure uniqueness of a certain
EReference in an EList (I mean, without explicitly scanning the whole list).

Usage would be:

I have many EList<? extends Identifiable>.
Identifiable has a field "name" (among other things).

I need to ensure NO EList has two elements with the same name.

But:
Two DIFFERENT Elist CAN have elements with the same name.
I can tolerate any number of "unnamed" (id.getName()==null ||
id.getName().isEmpty()) elements in the same EList.

What's Best Practice to implement this?

TiA
Re: New EClass instance validation [message #1376204 is a reply to message #1374408] Fri, 23 May 2014 05:58 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26013
Registered: July 2009
Senior Member
Mauro,

Comments below.

On 22/05/2014 6:20 PM, Mauro Condarelli wrote:
> Hi, is there some automagic way to ensure uniqueness of a certain
> EReference in an EList (I mean, without explicitly scanning the whole
> list).
>
> Usage would be:
>
> I have many EList<? extends Identifiable>.
> Identifiable has a field "name" (among other things).
>
> I need to ensure NO EList has two elements with the same name.
>
> But:
> Two DIFFERENT Elist CAN have elements with the same name.
> I can tolerate any number of "unnamed" (id.getName()==null ||
> id.getName().isEmpty()) elements in the same EList.
>
> What's Best Practice to implement this?
On any EReference you can set the eKeys property to be the combination
of attributes on the EReferences eReferenceType (i.e., the EClass that
is the type of the EReference) that must be unique. Of course this is
only useful for multi-valued references. This does induce a constraint
that will be automatically validated with all your other built-in
constraints. Also, if you do this for a containment reference, it will
affect the serialization, i.e., instead of @<feature-name>.<index>
you'll get @<feature-name>[<key>='<value>'].
>
> TiA
Re: New EClass instance validation [message #1381203 is a reply to message #1376204] Sun, 25 May 2014 08:35 Go to previous messageGo to next message
Felix Dorner is currently offline Felix Dorner
Messages: 206
Registered: March 2012
Senior Member
On 23/05/2014 11:58, Ed Merks wrote:

>> What's Best Practice to implement this?
> On any EReference you can set the eKeys property to be the combination
> of attributes on the EReferences eReferenceType (i.e., the EClass that
> is the type of the EReference) that must be unique. Of course this is
> only useful for multi-valued references. This does induce a constraint
> that will be automatically validated with all your other built-in
> constraints. Also, if you do this for a containment reference, it will
> affect the serialization, i.e., instead of @<feature-name>.<index>
> you'll get @<feature-name>[<key>='<value>'].

That's a sick pro tip Ed :). Is this on the wiki or doc somewhere?

Felix
Re: New EClass instance validation [message #1381873 is a reply to message #1381203] Sun, 25 May 2014 15:27 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26013
Registered: July 2009
Senior Member
Felix,

You'd normally need to hire me as a consultant to learn such secrets. :-P

On 25/05/2014 2:35 PM, Felix Dorner wrote:
> On 23/05/2014 11:58, Ed Merks wrote:
>
>>> What's Best Practice to implement this?
>> On any EReference you can set the eKeys property to be the combination
>> of attributes on the EReferences eReferenceType (i.e., the EClass that
>> is the type of the EReference) that must be unique. Of course this is
>> only useful for multi-valued references. This does induce a constraint
>> that will be automatically validated with all your other built-in
>> constraints. Also, if you do this for a containment reference, it will
>> affect the serialization, i.e., instead of @<feature-name>.<index>
>> you'll get @<feature-name>[<key>='<value>'].
>
> That's a sick pro tip Ed :). Is this on the wiki or doc somewhere?
>
> Felix
>
>
Re: New EClass instance validation [message #1383069 is a reply to message #1381203] Mon, 26 May 2014 03:35 Go to previous message
Mauro Condarelli is currently offline Mauro Condarelli
Messages: 417
Registered: September 2009
Senior Member
Il 25/05/2014 14:35, Felix Dorner ha scritto:
> On 23/05/2014 11:58, Ed Merks wrote:
>
>>> What's Best Practice to implement this?
>> On any EReference you can set the eKeys property to be the combination
>> of attributes on the EReferences eReferenceType (i.e., the EClass that
>> is the type of the EReference) that must be unique. Of course this is
>> only useful for multi-valued references. This does induce a constraint
>> that will be automatically validated with all your other built-in
>> constraints. Also, if you do this for a containment reference, it will
>> affect the serialization, i.e., instead of @<feature-name>.<index>
>> you'll get @<feature-name>[<key>='<value>'].
>
> That's a sick pro tip Ed :). Is this on the wiki or doc somewhere?
That's actually in the book (at least), but You need to pay attention:
In my case I have most of my EClasses deriving from a single one
(Whatever->Identifiable) and I faced problem the key (Identifiable.id)
must be unique across *all* instances of *derived* EClasses, So I had to
introduce a composite Identifiable.eID Attribute dynamically built from
actual EClass name plus id field. Done that it runs like a champ ;)

Mauro
Previous Topic:Errors in generated java code when extending Xcore
Next Topic:EMF - How to restrict values of non-containment references?
Goto Forum:
  


Current Time: Thu Aug 28 23:33:24 EDT 2014

Powered by FUDForum. Page generated in 0.02380 seconds