Home » Modeling » EMF » Validation question
| |
| Re: Validation question [message #422858 is a reply to message #422667] |
Wed, 17 September 2008 14:13   |
 Eric Rizzo
Messages: 3070
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 |
Ed Merks
Messages: 33140
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Wed Apr 24 16:28:04 GMT 2024
Powered by FUDForum. Page generated in 0.03709 seconds |
] 
Search
Help
Register
Login
Home
