Profile Tag Definition doesn't propagate Default Default value

[Paolo F Cantoni]

No, that's NOT a typo...

We have a profile Tag defined in the MDG as:

Code: [Select]

<DataRow>
<Column name="Property" value="MeasureNature"/>
<Column name="Description" value="Nature of a measure (such as KPI)"/>
<Column name="Notes" value=";v1.0 (pre) 1-Jan-2018&#xA;Type=Enum;&#xA;Values=Indeterminate,KPI,NKPI,Simple;&#xA;Default=Indeterminate;"/>
</DataRow>
As you can see, the default value is: "Indeterminate"

The metatype includes the reference to MeasureNature thus:

Code: [Select]

<TaggedValues>
<Tag name="MeasureNature"/>
</TaggedValues>
However, if you "Synchronize Stereotype", the Tag is created, but the default value is not assigned.

Apparently, you need to add a default value to the metatype thus:

Code: [Select]

<TaggedValues>
<Tag name="MeasureNature" default="Indeterminate"/>
</TaggedValues>
Now, when you "Synchronize Stereotype", the default value is assigned (but also, and unexpectedly to me, the Notes column is populated with the "Default: Indeterminate" value).  I was expecting only one instance to be updated, but instead, they all were!  Disconcerting to say the least!  I had to dig into the t_objectproperties table to figure out what EA had done.

BTW, there is no requirement that the default value at the metatype is the same as that at the main tag definition

Reported,
Paolo

[Paolo F Cantoni]

Sparx has advised it's been fixed in build 1528.  On the affected machines, it was 1528.

A quick test reveals significant changes in functionality!

Yes, the default "default" value is now populated correctly for new items. No it's not, I spoke too soon! 
AND the notes field is no longer populated if there is only a default "default" which (I think) restores the previous functionality.  The reason it's NOT, probably, is because the value is NOT persisted to the DB!

(but also, and unexpectedly to me, the Notes column is populated with the "Default: Indeterminate" value).  I was expecting only one instance to be updated, but instead, they all were!  Disconcerting to say the least!  I had to dig into the t_objectproperties table to figure out what EA had done.

BTW, there is no requirement that the default value at the metatype is the same as that at the main tag definition

However, if the individual metatype which uses the profile tag, specifies its own default, EA correctly places the metatype default but STILL places a value in the Notes Field.
If it's not needed for the profile default, why is it there for the metatype default.
If it is inserted at the metatype level WHY isn't it inserted at the profile level.  Since the first part of the GUID is the same regardless of whether the default is at the metatype level or the profile level - EA should see them as the same thing!

What is the rationale?

Overall, a D- for lack of real improvement.

AND FINALLY, like Uffe earlier, WHY is it that I have to test the absurd functionality? 

Unlike the developers, but like Uffe, I have to build models that ACTUALLY work for my users.  While these absurd inconsistencies exist, my life is wasted trying to figure out what EA is doing testing bug fixes that don't fix the bug.

Paolo  "using EA in spite of EA not because of it"

[Eve]

Well, on behalf of our support team I apologize. We misinterpreted the issue you reported.

The only change in 1528 related to tagged values of any sort was a fix for an issue where editing the value of a profile connector tag the notes would be lost. For some reason that I don't understand, they interpreted your report as being related. Maybe they thought they saw a change like you initially did.

I would expect the behavior you have described to be identical in 1527 and probably a long time further back.

[Paolo F Cantoni]

Well, on behalf of our support team I apologize. We misinterpreted the issue you reported.

[SNIP]

Apology accepted.

Anyone can make a mistake.

Paolo

[Paolo F Cantoni]

OK, having accepted the apology, there is still the issue that a mistake was made in interpreting my issue.

Just to be clear...

The pattern for such mechanisms needs to be:  Where a default value is supplied, and the Tag is created, the value of the default MUST be persisted to the DB.

The only change in 1528 related to tagged values of any sort was a fix for an issue where editing the value of a profile connector tag the notes would be lost.

If the metatype defines the default value, this appears to be STILL the case - so the fix... Didn't!

As far as I can see, there is NO point in copying the Tag definition into the Notes field under ANY circumstances.

Can we discuss if agreement is not possible?

Paolo

[Eve]

The pattern for such mechanisms needs to be:  Where a default value is supplied, and the Tag is created, the value of the default MUST be persisted to the DB.

This is one of those situations we discussed where such a change would be a breaking change for some users.

As far as I can see, there is NO point in copying the Tag definition into the Notes field under ANY circumstances.

I can't see a good reason for it. I'm assuming it was done for a reason once upon a time.

[Paolo F Cantoni]

The pattern for such mechanisms needs to be:  Where a default value is supplied, and the Tag is created, the value of the default MUST be persisted to the DB.

This is one of those situations we discussed where such a change would be a breaking change for some users.

As far as I can see, there is NO point in copying the Tag definition into the Notes field under ANY circumstances.

I can't see a good reason for it. I'm assuming it was done for a reason once upon a time.

In case you hadn't noticed we have breaking changes regardless   

On a more serious note, I'm sure we users would rather have fixes that finally rectify issues (such as this) even if it means (potentially^[1]) breaking the models.  We just need to be warned that they're coming and be able to plan for them.

From a "fact" point of view, persisting the default value into the DB CAN'T, by definition, break anything since the UI reports that the tag has the "default" value.  Since the actual (persisted) value in the DB is NULL^[2], you can't tell how the NULL got there (intentionally or by accident). So the UI may NOT be reporting the "true" fact of the tag.  Whereas, persisting the value clearly persists the fact correctly.

Paolo

^[1] For our part, when we find situations where things are "stuffed", we tend NOT to use them.  In this case, we (I) weren't aware that the default value WASN'T being persisted to the DB in all cases until we looked.  This was after a decade of use!

^[2] AS is obvious by now, I HATE NULLs!   

[Geert Bellekens]

I agree with Paolo.

It would be a lot better if the default value was persisted.

Geert