Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Ecore Metamodel EAttribute bugs(bugs linked to the multiplicity of EAttribute)
icon4.gif  Ecore Metamodel EAttribute bugs [message #917957] Thu, 20 September 2012 15:43 Go to next message
Dario Imparato is currently offline Dario ImparatoFriend
Messages: 20
Registered: August 2012
Junior Member
Hello,
I am sorry if what I am going to ask has already been asked in another post but I have not found it.
I have 2 problems.
1)Suppose you create an Ecore metamodel with an "Eclass" in it and an "EAttribute " called "Value" of type "EInt". Suppose Value has NO "Default Value Literal" and has "Lower Bound" =0 and "Upper Bound" =1; if you create a model using this metamodel, Value appears with default value "0" and if you open it with text editor, "Value" field is not present.Same problem with "EFloat" type.
So the first problem is that "0" is not considered as an integer.

2)Suppose Value is an "EString" and has "Lower Bound" =1 and "Upper Bound" =1, so it is a required attribute; if you don't specify it in the model, an empty string ("") will be assigned and if you try to validate the model you will have no problem.
So the second problem is that I cannot control if a required attribute of type "Estring" has been specified.

Are these bugs? What do you think about it?
Thanks in advance.
Re: Ecore Metamodel EAttribute bugs [message #918143 is a reply to message #917957] Thu, 20 September 2012 19:39 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Dario,

Comments below.

On 20/09/2012 5:43 PM, Dario Imparato wrote:
> Hello,
> I am sorry if what I am going to ask has already been asked in
> another post but I have not found it.
> I have 2 problems.
> 1)Suppose you create an Ecore metamodel with an "Eclass" in it and an
> "EAttribute " called "Value" of type "EInt". Suppose Value has NO
> "Default Value Literal" and has "Lower Bound" =0 and "Upper Bound" =1;
> if you create a model using this metamodel, Value appears with default
> value "0"
Of course a primitive must have a value...
> and if you open it with text editor, "Value" field is not present.
You mean in the serialization?
> Same problem with "EFloat" type.
Yes, all the primitives have an intrinsic default of zero.
> So the first problem is that "0" is not considered as an integer.
By what?
>
> 2)Suppose Value is an "EString" and has "Lower Bound" =1 and "Upper
> Bound" =1, so it is a required attribute; if you don't specify it in
> the model, an empty string ("") will be assigned and if you try to
> validate the model you will have no problem.
Assigned by whome?
> So the second problem is that I cannot control if a required attribute
> of type "Estring" has been specified.
I don't follow what you're saying.
>
> Are these bugs?
I doubt there are bugs in these basic things after 10 years of wide
spread use.
> What do you think about it?
I think I don't understand what you're saying. Yes, primitives must
have a value. Default values are not serialized, i.e., if eIsSet if
false, nothing will appear in the XMI/XML. In general, binding
String-valued features to text fields suffers from the problem that you
can't distinguish null from the empty string. The properties view lets
you reset a value to the default (little button in the view bar areas),
so if a String-valued feature has no default, you can use that to set it
back to null.
> Thanks in advance.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Ecore Metamodel EAttribute bugs [message #918693 is a reply to message #918143] Fri, 21 September 2012 08:59 Go to previous messageGo to next message
Dario Imparato is currently offline Dario ImparatoFriend
Messages: 20
Registered: August 2012
Junior Member
Ed,
comments below.
Quote:
You mean in the serialization?

Yes, but I don't understand when you say that a primitive must have a value...
Question: if I had an optional attribute of type "EInt", how could I assign "0" value to it? I tried it and in the serialized file (.xmi) I have not the specific xml attribute.

Quote:

> an empty string ("") will be assigned and if you try to
> validate the model you will have no problem.
Assigned by whome?

By the editor plug-in that is created by the genmodel.

Quote:
> So the second problem is that I cannot control if a required attribute
> of type "Estring" has been specified.
I don't follow what you're saying.

I can not distinguish an empty string from a null, but as you said it must be used "Restore default value" to avoid the problem (imho it's a weak workaround)

Now I have another issue, if I had a meta-model class "ClassChild" that inherited from a parent "ClassFather" and the latter has a required attribute (no matter what type), it is not inherited as "required" in "ClassChild" .
So if "ClassChild" is present without the required attribute, the validation of the model, performed by the editor, goes fine.

Suggestions?
Re: Ecore Metamodel EAttribute bugs [message #918751 is a reply to message #918693] Fri, 21 September 2012 09:58 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Dario,

Comments below.

On 21/09/2012 10:59 AM, Dario Imparato wrote:
> Ed,
> comments below.
> Quote:
>> You mean in the serialization?
>
> Yes, but I don't understand when you say that a primitive must have a
> value...
Consider when you have a field declared in Java of type int and you
don't initialize it. What value will it have? For all primitives, it's
the zero value; for everything else it's null.
> Question: if I had an optional attribute of type "EInt", how could I
> assign "0" value to it?
In the Ecore model you can set the default value literal for an
EAttribute to "0", but even if you don't, it will still have that
default value because primitive types have an intrinsic default; they
can't be null because they're not java.lang.Objects.
> I tried it and in the serialized file (.xmi) I have not the specific
> xml attribute.
This is a third question. As I said, feature will be serialized only if
it's considered set. For non-unsettable features, that will be the case
only when the value is different from the default value. And, as I've
explained above, primitives always have a default value, either explicit
or intrinsic. This save option can force explicit (not intrinsic)
defaults to be serialized

/**
* Keep default content ( e.g. default attributes). This applies to
saving and converting contents to DOM.
* By default the default content is discarded.
* To save the default content, set this option to
<code>Boolean.TRUE</code>.
*/
String OPTION_KEEP_DEFAULT_CONTENT = "KEEP_DEFAULT_CONTENT";

So if you set the explicit default to "0" and use this option, you will
see values serialized for features that not not set up have an explicit
default in the Ecore model.
>
> Quote:
>> > an empty string ("") will be assigned and if you try to > validate
>> the model you will have no problem.
>> Assigned by whome?
>
> By the editor plug-in that is created by the genmodel.
You mean in the properties view?
>
> Quote:
>> > So the second problem is that I cannot control if a required
>> attribute > of type "Estring" has been specified.
>> I don't follow what you're saying.
>
> I can not distinguish an empty string from a null, but as you said it
> must be used "Restore default value" to avoid the problem (imho it's a
> weak workaround)
Yes, but consider that this problem is everywhere in every dialog you
see. For some reason no one (even the folks providing data binding
support) seems to care about it.
>
> Now I have another issue, if I had a meta-model class "ClassChild"
> that inherited from a parent "ClassFather" and the latter has a
> required attribute (no matter what type), it is not inherited as
> "required" in "ClassChild" .
Yes it is.
> So if "ClassChild" is present without the required attribute, the
> validation of the model, performed by the editor, goes fine.
No, I don't think so. But again, the nature of primitives has an
impact. Look in
org.eclipse.emf.ecore.util.EObjectValidator.validate_MultiplicityConforms(EObject,
EStructuralFeature, DiagnosticChain, Map<Object, Object>) and look at

else if (eStructuralFeature.isRequired())
{
if (eStructuralFeature.isUnsettable() ?
!eObject.eIsSet(eStructuralFeature) : eObject.eGet(eStructuralFeature,
false) == null)
{
result = false;
if (diagnostics != null)
{
diagnostics.add
(createDiagnostic
(Diagnostic.ERROR,
DIAGNOSTIC_SOURCE,
EOBJECT__EVERY_MULTIPCITY_CONFORMS,
"_UI_RequiredFeatureMustBeSet_diagnostic",
new Object [] { getFeatureLabel(eStructuralFeature,
context), getObjectLabel(eObject, context) },
new Object [] { eObject, eStructuralFeature },
context));
}
}
}

See that it only diagnoses a problem if there is no value, but for
primitives there's always a value.
>
> Suggestions?


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Ecore Metamodel EAttribute bugs [message #918816 is a reply to message #917957] Fri, 21 September 2012 11:19 Go to previous messageGo to next message
Christoph Keimel is currently offline Christoph KeimelFriend
Messages: 482
Registered: December 2010
Location: Germany
Senior Member
Hi Dario

If you want to be able to set your attribute "Value" to null, you can use EIntegerObject as a type. The attribute will then be an Integer object instead of a primitive int.

Another possibility is to mark the attribute as "Unsettable". You can then test, if the attribute has been set und you can "unset" it (as an alternative to setting it to null).

Greetings
Christoph
Re: Ecore Metamodel EAttribute bugs [message #918918 is a reply to message #918751] Fri, 21 September 2012 13:34 Go to previous messageGo to next message
Dario Imparato is currently offline Dario ImparatoFriend
Messages: 20
Registered: August 2012
Junior Member
Ed,
comments below.
I understood that primitives must have a default value, but so why "EAttribute" can have "Lower Bound" to 0 for these types?
In a metamodel I can have a Class with an optional attribute of a primitive type (i.e. EInt) so when I create a model (istance of my metamodel) with a Class MYClass, I have to specify the optional attribute and for me it is a nonsense, doesn't it?

Quote:
> Now I have another issue, if I had a meta-model class "ClassChild"
> that inherited from a parent "ClassFather" and the latter has a
> required attribute (no matter what type), it is not inherited as
> "required" in "ClassChild" .
Yes it is.


Try this. Create an "EClass" A with an "EAttribute" name of type "EString", create an "EClass" B inherited from A. Create now the model from this meta-model with a class BClass of kind B WITHOUT specifying name. If name is required, you will not be able to validate it, right?
On the contrary, validation goes fine, while if you try to make the same with a class AClass of kind A you will not.

As suggested by Christoph, using EIntegerObject is a solution to create an effectively optional EAttribute for primitive types, while setting "Unsettable" an "EInt" doesn't solve the problem: the attribute still has "0" as default value.
Thanks a lot.
Re: Ecore Metamodel EAttribute bugs [message #918932 is a reply to message #918918] Fri, 21 September 2012 13:51 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Dario,

Comments below.

On 21/09/2012 3:34 PM, Dario Imparato wrote:
> Ed,
> comments below.
> I understood that primitives must have a default value, but so why
> "EAttribute" can have "Lower Bound" to 0 for these types?
You're suggesting the Ecore model's validator should diagnose an error
when the attribute's type is a primitive and the attribute is not also
unsettable?
> In a metamodel I can have a Class with an optional attribute of a
> primitive type (i.e. EInt) so when I create a model (istance of my
> metamodel) with a Class MYClass, I have to specify the optional
> attribute and for me it is a nonsense, doesn't it?
Sorry, I can't make sense of the phrase "I have to specify an optional
attribute". You don't have to set a value for an optional attribute.
>
> Quote:
>> > Now I have another issue, if I had a meta-model class "ClassChild"
>> > that inherited from a parent "ClassFather" and the latter has a >
>> required attribute (no matter what type), it is not inherited as >
>> "required" in "ClassChild" . Yes it is.
>
>
> Try this. Create an "EClass" A with an "EAttribute" name of type
> "EString", create an "EClass" B inherited from A. Create now the model
> from this meta-model with a class BClass of kind B WITHOUT specifying
> name. If name is required, you will not be able to validate it, right?
When I do that, and don't set a value for B's name, it diagnoses that as
an error.
> On the contrary, validation goes fine, while if you try to make the
> same with a class AClass of kind A you will not.
It also complains when an A instances doesn't have the name set.

How are you doing the validation?
>
> As suggested by Christoph, using EIntegerObject is a solution to
> create an effectively optional EAttribute for primitive types, while
> setting "Unsettable" an "EInt" doesn't solve the problem: the
> attribute still has "0" as default value.
> Thanks a lot.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Ecore Metamodel EAttribute bugs [message #919071 is a reply to message #918693] Fri, 21 September 2012 16:50 Go to previous messageGo to next message
Maximilian Koegel is currently offline Maximilian KoegelFriend
Messages: 253
Registered: July 2009
Senior Member
Hi,

considering one of the questions, I might have an answer ;):
> value...
> Question: if I had an optional attribute of type "EInt", how could I
> assign "0" value to it? I tried it and in the serialized file (.xmi) I
> have not the specific xml attribute.
The value does not appear in the serialization because it is the same as
the DEFAULT value. You can view this as an optimization to save some
bytes in the serialization. If you do not specify a default value the
defualt for the default value is 0.

Cheers,
Maximilian

>
> Quote:
>> > an empty string ("") will be assigned and if you try to > validate
>> the model you will have no problem.
>> Assigned by whome?
>
> By the editor plug-in that is created by the genmodel.
>
> Quote:
>> > So the second problem is that I cannot control if a required
>> attribute > of type "Estring" has been specified.
>> I don't follow what you're saying.
>
> I can not distinguish an empty string from a null, but as you said it
> must be used "Restore default value" to avoid the problem (imho it's a
> weak workaround)
>
> Now I have another issue, if I had a meta-model class "ClassChild" that
> inherited from a parent "ClassFather" and the latter has a required
> attribute (no matter what type), it is not inherited as "required" in
> "ClassChild" . So if "ClassChild" is present without the required
> attribute, the validation of the model, performed by the editor, goes fine.
>
> Suggestions?


--
Maximilian Kögel

Get Professional Eclipse Support: http://eclipsesource.com/munich
Re: Ecore Metamodel EAttribute bugs [message #921801 is a reply to message #918932] Mon, 24 September 2012 12:45 Go to previous messageGo to next message
Dario Imparato is currently offline Dario ImparatoFriend
Messages: 20
Registered: August 2012
Junior Member
Quote:
You're suggesting the Ecore model's validator should diagnose an error
when the attribute's type is a primitive and the attribute is not also
unsettable?

I say that, for primitive attributes, the Ecore model's validator can't distinguish between the case where the attribute has been assigned and the case where the attribute has been not assigned. For tools that take the model as input and require to understand if the value as been assigned or not, it is a problem...

Quote:
> Try this. Create an "EClass" A with an "EAttribute" name of type
> "EString", create an "EClass" B inherited from A. Create now the model
> from this meta-model with a class BClass of kind B WITHOUT specifying
> name. If name is required, you will not be able to validate it, right?
When I do that, and don't set a value for B's name, it diagnoses that as
an error.

You are right. I deleted and recreated "name" attribute and now if I don't set a value for B's name, it diagnoses that as an error. I don't know why there was this problem before. Thanks Ed

Quote:
The value does not appear in the serialization because it is the same as
the DEFAULT value. You can view this as an optimization to save some
bytes in the serialization. If you do not specify a default value the
defualt for the default value is 0.

Thanks Maximilian
Re: Ecore Metamodel EAttribute bugs [message #921859 is a reply to message #921801] Mon, 24 September 2012 13:49 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Dario,

Comments below.

On 24/09/2012 2:45 PM, Dario Imparato wrote:
> Quote:
>> You're suggesting the Ecore model's validator should diagnose an
>> error when the attribute's type is a primitive and the attribute is
>> not also unsettable?
>
> I say that, for primitive attributes, the Ecore model's validator
> can't distinguish between the case where the attribute has been
> assigned and the case where the attribute has been not assigned.
Even for non-primitives it can't distinguish between the default and an
assigned value equal to the default.
> For tools that take the model as input and require to understand if
> the value as been assigned or not, it is a problem...
Either the tool needs to work for all models (the EMF runtime does), or
they can insist that features be unsettable because that's the only way
to know if the value you get back is there because it's been assigned
verses it's there because it's the default.
>
> Quote:
>> > Try this. Create an "EClass" A with an "EAttribute" name of type >
>> "EString", create an "EClass" B inherited from A. Create now the
>> model > from this meta-model with a class BClass of kind B WITHOUT
>> specifying > name. If name is required, you will not be able to
>> validate it, right?
>> When I do that, and don't set a value for B's name, it diagnoses that
>> as an error.
>
> You are right. I deleted and recreated "name" attribute and now if I
> don't set a value for B's name, it diagnoses that as an error. I don't
> know why there was this problem before. Thanks Ed
>
> Quote:
>> The value does not appear in the serialization because it is the same as
>> the DEFAULT value. You can view this as an optimization to save some
>> bytes in the serialization. If you do not specify a default value the
>> defualt for the default value is 0.
>
> Thanks Maximilian


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Ecore Metamodel EAttribute bugs [message #921877 is a reply to message #921801] Mon, 24 September 2012 14:02 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

Hi, Dario,

On 2012-09-24 12:45:06 +0000, Dario Imparato said:

> Quote:
>> You're suggesting the Ecore model's validator should diagnose an error
>> when the attribute's type is a primitive and the attribute is not also
>> unsettable?
>
> I say that, for primitive attributes, the Ecore model's validator can't
> distinguish between the case where the attribute has been assigned and
> the case where the attribute has been not assigned. For tools that take
> the model as input and require to understand if the value as been
> assigned or not, it is a problem...

But, it can. If you designate the attribute as "unsettable", then EMF
generates an additional state variable that records whether a value has
been explicitly set in the feature or not. This additional state is
what the eIsSet()/eUnset() API works with. So, the validator (and any
code) can tell the difference between a 0 in an EInt attribute that
happens to be there because Java requires it and one that was
explicitly set as the intended value.

Note that "unsettable" does not indicate that a feature cannot be set.
It indicates that a feature can be unset.

HTH,

Christian
Re: Ecore Metamodel EAttribute bugs [message #922663 is a reply to message #921877] Tue, 25 September 2012 08:05 Go to previous messageGo to next message
Dario Imparato is currently offline Dario ImparatoFriend
Messages: 20
Registered: August 2012
Junior Member
Quote:
But, it can. If you designate the attribute as "unsettable", then EMF
generates an additional state variable that records whether a value has
been explicitly set in the feature or not. This additional state is
what the eIsSet()/eUnset() API works with. So, the validator (and any
code) can tell the difference between a 0 in an EInt attribute that
happens to be there because Java requires it and one that was
explicitly set as the intended value.

Thank you Christian, but I have a problem using "unsettable" flag.
If I want to set the value "0" to an "Unsettable" attribute of "EInt", I first have to assign another value (i.e. "1"), then have to save the model before reassign "0" value and finally save the model. In this way in the serialized file of the model (.xmi) I can find "value=0" field. Otherwise if I assign "0" value from the beginning, no "value" field appears in the serialized file of model, in fact I can't save the model because no changes are detected.
Any suggestions?
Re: Ecore Metamodel EAttribute bugs [message #922752 is a reply to message #922663] Tue, 25 September 2012 09:44 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
I imagine we could have a button, like the reset button, that sets the
value. If all this boils down to wanting serialized defaults then you
can specify the default explicitly in the model for each feature and use
the save option I mentioned previous to save those explicit defaults.


On 25/09/2012 10:05 AM, Dario Imparato wrote:
> Quote:
>> But, it can. If you designate the attribute as "unsettable", then EMF
>> generates an additional state variable that records whether a value
>> has been explicitly set in the feature or not. This additional state
>> is what the eIsSet()/eUnset() API works with. So, the validator (and
>> any code) can tell the difference between a 0 in an EInt attribute
>> that happens to be there because Java requires it and one that was
>> explicitly set as the intended value.
>
> Thank you Christian, but I have a problem using "unsettable" flag.
> If I want to set the value "0" to an "Unsettable" attribute of "EInt",
> I first have to assign another value (i.e. "1"), then have to save the
> model before reassign "0" value and finally save the model. In this
> way in the serialized file of the model (.xmi) I can find "value=0"
> field. Otherwise if I assign "0" value from the beginning, no "value"
> field appears in the serialized file of model, in fact I can't save
> the model because no changes are detected.
> Any suggestions?


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Ecore Metamodel EAttribute bugs [message #929267 is a reply to message #922752] Mon, 01 October 2012 10:28 Go to previous message
Dario Imparato is currently offline Dario ImparatoFriend
Messages: 20
Registered: August 2012
Junior Member
Thank you for your suggestions Ed.
I am using EIntegerObject and I don't have problems for now.
Previous Topic:CDO p2 Repository broken
Next Topic:[CDO] Crash on CDO after restart when using mongodb store
Goto Forum:
  


Current Time: Fri Mar 29 07:08:48 GMT 2024

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

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

Back to the top