|
| Re: New EClass instance validation [message #1376204 is a reply to message #1374408] |
Fri, 23 May 2014 09:58   |
 Ed Merks
Messages: 33140
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
|
| Re: New EClass instance validation [message #1383069 is a reply to message #1381203] |
Mon, 26 May 2014 07:35 |
Mauro Condarelli
Messages: 428
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
|
|
|
Powered by
FUDForum. Page generated in 0.03842 seconds
] 
Search
Help
Register
Login
Home
