|
|
|
| Re: Validation errors with multiple bidirectional containment references [message #525547 is a reply to message #525389] |
Tue, 06 April 2010 20:14   |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Henning,
Comments below.
groenda@fzi.de wrote:
> Hi Ed,
>
> i referred to the part of the model generation which provides for
> example the 'Validate'-functionality in the menu (via
> ValidateAction()) within the (generated) editor. As far as i know it
> uses the Diagnostic-related classes within org.eclipse.emf.ecore.util
> to diagnose errors or warnings of EObjects. I guessed that it uses the
> EMF Validation framework, however i am not sure of that.
Yes, but I still don't know exactly what you're taking issue with...
>
> Background: I used an ecore and EMF generator model to create the
> model-, edit-, editor-, and test-plugin for the model described in my
> initial post. When i create a model element in the editor and run
> validation it provides the error message that the required feature of
> class A must be set (for the containment-relation which does not hold).
So you have a feature for which the lower bound is >= 1? You've
specified that it must be set. If that's not the case, then make the
lower bound be zero.
> I just used the editor as it was easier. As far as i know i didn't use
> any features which were not available in 'pure' EMF.
>
> Thanks for your help,
> Henning
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
|
|
| Re: Validation errors with multiple bidirectional containment references [message #525979 is a reply to message #525951] |
Thu, 08 April 2010 12:47 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Henning,
Comments below.
groenda@fzi.de wrote:
> Hi Ed,
>
> Comments below.
>
>> > Two containment relations with the bound [1] on the source element
>> > and the same target element cannot be fulfilled, right?
>> Not by the same instance object.
> Which would lead for a model with bidirectional containment
> references A-1--*->B and C-1--*->B to the fact that B cannot be
> instantiated correctly. The problem ist definitely with the model but
> an according early error reporting would be nice for elements which
> are bidirectionally contained with 'source' bound 1 in more than one
> reference.
Even if only one container reference is defined for B, any other
containment references with B as a target, even ones without an opposite
and hence not necessarily known to B, will still imply a problem should
a B instance ever be added to any other containment reference.
>> > It would have helped me a lot if a got a according error message
>> > during EMF model generation.
>> What you've described so far doesn't appear to fit in that category
>> though.
> I hope i could point out my original intentions above.
>> > I assumed the model was correct and that there was an validation error
>> > because it is obvious that only one containment relation can hold for
>> > the instance of an element. A message during generation helps in
>> > finding the error faster than if i have to instantiate the element and
>> > the earlier error message could help by giving a hint at the bounds.
>> Are you really talking containment references or container references.
>> I suspect the latter...
> Most probably, but in my terms the container reference would mean the
> referenced EObject,e.g. for an established bidirectional containment
> reference for an instance EObject. A bidirectional containment
> reference with 'source' bound 1 would automatically imply a container
> reference. Hence, i assumed that if the model is not considered
> invalid it is okay for object instances that exactly one of the
> bidirectional containment references with 'source' bound 1 hold (and
> the other references are not considered anymore).
Wrong assumption.
We could add a constraint to Ecore. Perhaps the best way to specify it
would be to say that for any containment EReference x to an EClass X,
there must but no container reference y on X with lower bound 1 except
if y is x's opposite. This captures the case I mentioned above where
any other non-bidirectional containment reference to X will necessarily
cause a problem if X is required to be contained by something else.
Feel free to open a bugzilla for that.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.04104 seconds
] 
Search
Help
Register
Login
Home
