Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Validation question
Validation question [message #422654] Fri, 12 September 2008 02:28 Go to next message
Eric Rizzo is currently offline Eric RizzoFriend
Messages: 3071
Registered: July 2009
Senior Member
I've noticed that EAttributes that are completely derived (marked as
Derived, Transient, Volatile, NOT Changeable, and NOT Unsettable) still
get validated by EObjectValidator.validate(). Here is the stack
(upside-down):

EObjectValidator.validate()
EObjectValidator.validate_EveryDefaultConstraint()
EObjectValidator.validate_EveryDataValueConforms()
EObjectValidator.validate_DataValueConforms()
MyEObject.eIsSet()
MyEObject.getMyDerivedAttribute()

The problem with this comes when myDerivedAttribute is expensive to
calculate, because this ends up being called pretty frequently even when
nobody is actually requesting the value of myDerivedAttribute. It
doesn't make sense to me that an attribute that is non-persisted,
non-settable, and totally derived should be validated at all.

A) Is there a way to exclude this attribute from EObjectValidator's radar?

B) Is there merit to my thought that such attributes should never be
validated?

Eric
Re: Validation question [message #422667 is a reply to message #422654] Fri, 12 September 2008 11:32 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30813
Registered: July 2009
Senior Member
Eric,

Comments below.

Eric Rizzo wrote:
> I've noticed that EAttributes that are completely derived (marked as
> Derived, Transient, Volatile, NOT Changeable, and NOT Unsettable)
> still get validated by EObjectValidator.validate(). Here is the stack
> (upside-down):
>
> EObjectValidator.validate()
> EObjectValidator.validate_EveryDefaultConstraint()
> EObjectValidator.validate_EveryDataValueConforms()
> EObjectValidator.validate_DataValueConforms()
> MyEObject.eIsSet()
> MyEObject.getMyDerivedAttribute()
>
> The problem with this comes when myDerivedAttribute is expensive to
> calculate, because this ends up being called pretty frequently even
> when nobody is actually requesting the value of myDerivedAttribute. It
> doesn't make sense to me that an attribute that is non-persisted,
> non-settable, and totally derived should be validated at all.
Sure. It could produce an invalid value depending on fully valid values
of other attributes...
>
> A) Is there a way to exclude this attribute from EObjectValidator's
> radar?
Not without specializing the validator of the package of the class of
that attribute.
>
> B) Is there merit to my thought that such attributes should never be
> validated?
No. :-P You could make the feature be unsettable and always return
false for the isSetX; of course you'd not want it to be required in that
case. And you could suppress the isSetX method from the API so that
clients don't see that method.
>
> Eric
Re: Validation question [message #422858 is a reply to message #422667] Wed, 17 September 2008 14:13 Go to previous messageGo to next message
Eric Rizzo is currently offline Eric RizzoFriend
Messages: 3071
Registered: July 2009
Senior Member
Ed Merks wrote:
> Eric,
>
> Comments below.
>
> Eric Rizzo wrote:
>> I've noticed that EAttributes that are completely derived (marked as
>> Derived, Transient, Volatile, NOT Changeable, and NOT Unsettable)
>> still get validated by EObjectValidator.validate(). Here is the stack
>> (upside-down):
>>
>> EObjectValidator.validate()
>> EObjectValidator.validate_EveryDefaultConstraint()
>> EObjectValidator.validate_EveryDataValueConforms()
>> EObjectValidator.validate_DataValueConforms()
>> MyEObject.eIsSet()
>> MyEObject.getMyDerivedAttribute()
>>
>> The problem with this comes when myDerivedAttribute is expensive to
>> calculate, because this ends up being called pretty frequently even
>> when nobody is actually requesting the value of myDerivedAttribute. It
>> doesn't make sense to me that an attribute that is non-persisted,
>> non-settable, and totally derived should be validated at all.
> Sure. It could produce an invalid value depending on fully valid values
> of other attributes...

I don't understand how that is logical. If a "completely derived" (ie,
derived, transient, volatile, and not changeable) attribute produced an
invalid value from otherwise valid state, wouldn't that represent a
programming error in the implementation of the derivation? I don't see
how it is a validation problem, which is supposed to be a runtime
problem as opposed to an implementation error, no?

Furthermore, why is getX() invoking a call to eIsSet() for a feature
that is NOT unsettable? If it is not unsettable, why bother asking if it
is set?

Even more specifically, what is the meaning of a "completely derived"
attribute being unset? That just doesn't make any sense to me at all,
because it is derived it can't ever be unset (at least in my mind, but
I'm willing to be enlightened).


>> B) Is there merit to my thought that such attributes should never be
>> validated?
> No. :-P You could make the feature be unsettable and always return
> false for the isSetX; of course you'd not want it to be required in that
> case. And you could suppress the isSetX method from the API so that
> clients don't see that method.

As you know, we're not big fans of modifying the generated code any more
than is absolutely necessary. So I'm looking for a way to structure the
model properly rather than hack up the impl code, if possible. If my
question/objection/misunderstanding above can be answered/corrected,
hopefully I won't have to resort to impl hacks to avoid the expensive
and unnecessary isSet checks.

Thanks,
Eric
Re: Validation question [message #422859 is a reply to message #422858] Wed, 17 September 2008 14:37 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30813
Registered: July 2009
Senior Member
Eric,

Comments below.

Eric Rizzo wrote:
> Ed Merks wrote:
>> Eric,
>>
>> Comments below.
>>
>> Eric Rizzo wrote:
>>> I've noticed that EAttributes that are completely derived (marked as
>>> Derived, Transient, Volatile, NOT Changeable, and NOT Unsettable)
>>> still get validated by EObjectValidator.validate(). Here is the
>>> stack (upside-down):
>>>
>>> EObjectValidator.validate()
>>> EObjectValidator.validate_EveryDefaultConstraint()
>>> EObjectValidator.validate_EveryDataValueConforms()
>>> EObjectValidator.validate_DataValueConforms()
>>> MyEObject.eIsSet()
>>> MyEObject.getMyDerivedAttribute()
>>>
>>> The problem with this comes when myDerivedAttribute is expensive to
>>> calculate, because this ends up being called pretty frequently even
>>> when nobody is actually requesting the value of myDerivedAttribute.
>>> It doesn't make sense to me that an attribute that is non-persisted,
>>> non-settable, and totally derived should be validated at all.
>> Sure. It could produce an invalid value depending on fully valid
>> values of other attributes...
>
> I don't understand how that is logical. If a "completely derived" (ie,
> derived, transient, volatile, and not changeable) attribute produced
> an invalid value from otherwise valid state, wouldn't that represent a
> programming error in the implementation of the derivation?
Typically, but not necessarily. Say you have a derived int property
that is the sum of two other int properties and this sum is constrained
to be within a certain range. The derivation is just z = x + y and
then constrainted to be 0 < z < 10...
> I don't see how it is a validation problem, which is supposed to be a
> runtime problem as opposed to an implementation error, no?
Typically that's true.
>
> Furthermore, why is getX() invoking a call to eIsSet() for a feature
> that is NOT unsettable? If it is not unsettable, why bother asking if
> it is set?
I'm not sure the context of your comment. In general, eIsSet is
implemented in one of two ways,:for unsettable features, it's an
additional state; for non-unsettable features, the value is compared
against the default.
>
> Even more specifically, what is the meaning of a "completely derived"
> attribute being unset?
It's up to you to give it meaning. Suppose it's derived from other
features all of which aren't set. It would be reasonable to argue that
the derived feature is therefore not set.
> That just doesn't make any sense to me at all, because it is derived
> it can't ever be unset (at least in my mind, but I'm willing to be
> enlightened).
You're looking at unset as a verb or an action, rather than a state.
>
>
>>> B) Is there merit to my thought that such attributes should never be
>>> validated?
>> No. :-P You could make the feature be unsettable and always return
>> false for the isSetX; of course you'd not want it to be required in
>> that case. And you could suppress the isSetX method from the API so
>> that clients don't see that method.
>
> As you know, we're not big fans of modifying the generated code any
> more than is absolutely necessary.
It's also difficult to change behavior of things on which clients
already depend when the current behavior is not clearly just a bug.
> So I'm looking for a way to structure the model properly rather than
> hack up the impl code, if possible. If my
> question/objection/misunderstanding above can be answered/corrected,
> hopefully I won't have to resort to impl hacks to avoid the expensive
> and unnecessary isSet checks.
One might argue that a derived feature perhaps ought never be considered
set. Ultimately your issue seems to be one of performance, rather than
correctness, so if you need to make changes to improve performance, that
seems reasonable. You could of course specialize your validator as well
to ignore specific features, but that's just another way to modify the code.

I just don't feel I'm in a position to say hey, we've decided now that
we'll no longer validate derived features even though we were before...
>
> Thanks,
> Eric
Previous Topic:[CDO] Using CDO with editors based on Transactional Editing Domain
Next Topic:Richer EMF model than the one generated by XSD
Goto Forum:
  


Current Time: Wed Jan 22 16:41:06 GMT 2020

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

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

Back to the top