Composition with direction arrow after migration from v14 to v16

[mariop]

Hm. Are you sure about this?

For any given combination, I see Direction value changes for these rows, but Navigable values remains 0.

Mario.

[qwerty]

Never thought about this, but having the properties this way looks like bad redundancy. No wonder there are issues.

q.

[Geert Bellekens]

Hm. Are you sure about this?

For any given combination, I see Direction value changes for these rows, but Navigable values remains 0.

Mario.

Hmm, I did a quick test, and it seems that indeed in v16 the columns SourceIsNavigable and DestIsNavigable are no longer used, they stay at 0 (but "old" values are not updated)
Instead they are updating the SourceStyle and DestStyle columns and adding another key-value pair like: "Navigable=Non-Navigable;"

Pff, so they had a normalized separate column for this information, but they decided to not use that anymore and instead hack this info into the "style" columns?
If we are going that way, we might as well get rid of all those pesky columns. Instead each table could have a single column with keyvalue pairs!!

Not sure since when this has changed exactly, but it might be a serious problem for those of us thinking about upgrading to v16.

I would definitely report it as a bug.

Geert

[Paolo F Cantoni]

The problem, in part, comes about because Sparx has conflated Directionality with Navigability.  One property (Directionality) relates to how the line should be drawn. The other (Navigabilioty) with whether the arrows should be drawn.

We have standardised on ALL relationships having directionality = Source -> Destination and ensured the semantics are therefore correct.  In over 200,000 relationships we maintain, all are so designated.  Navigability is set as required.

While this conflation remains, different relationships created at different times by different versions of EA will behave differently.

HTH,
Paolo

[Geert Bellekens]

It seems like this change dates from before v16.

I tested this in v15, and the IsNavigable fields remain 0 there as well.

Geert

[Paolo F Cantoni]

Hm. Are you sure about this?

For any given combination, I see the Direction value changes for these rows, but Navigable values remain 0.

Mario.

Hmm, I did a quick test, and it seems that indeed in v16, the columns SourceIsNavigable and DestIsNavigable are no longer used; they stay at 0 (but "old" values are not updated)
Instead, they are updating the SourceStyle and DestStyle columns and adding another key-value pair like: "Navigable=Non-Navigable;"

Pff, so they had a normalized separate column for this information, but they decided not to use that anymore and instead hack this info into the "style" columns?
If we are going that way, we might as well get rid of all those pesky columns. Instead, each table could have a single column with key-value pairs!!

Not sure when this has changed exactly, but it might be a serious problem for those of us thinking about upgrading to v16.

I would definitely report it as a bug.

Geert

Sheesh!
"Navigable=Non-Navigable" is very confusing.  If they were going to do that, then it should at least be "Navigability=Non-Navigable".
But as you ask, Geert, why change?  Well, the reason would appear to be that they are now able to include an extrinsic value "Navigable=Unspecified".  This is not possible where SourceIsNavigable and DestIsNavigable are boolean values.
I have found a number of connectors with Source unspecified, Destination Navigable, in line with my previous post.

If it had been my design decision (with no loss of generality - as the Mathematicians say), I would have STILL set SourceIsNavigable and DestIsNavigable to true if Navigable=Navigable for the respective end.  That would have been better than false, regardless.  But then, what would I know? I'm just a data architect who passed "Thinking 101".

Paolo

[qwerty]

Pff, so they had a normalized separate column for this information, but they decided to not use that anymore and instead hack this info into the "style" columns?
If we are going that way, we might as well get rid of all those pesky columns. Instead each table could have a single column with keyvalue pairs!!

I presume that Sparx does not have any data architect (looking at the ever conflating StyleEx columns in various tables). So prepare for more confusion in the future.

q.

[Geert Bellekens]

But as you ask, Geert, why change?  Well, the reason would appear to be that they are now able to include an extrinsic value "Navigable=Unspecified".  This is not possible where SourceIsNavigable and DestIsNavigable are boolean values.

One would think that, but if I look into my database I find values

* 1 => Navigable
* 0 => Unspecified
* -1 => Not Navigable

I really don't see why they would want to move from a clearly defined normalised scheme to a scheme that relies on descriptions somewhere in a text field.

Geert

[mariop]

OK, one thing is weird representation in database, but this non-consistency in class diagram (arrow being present only in some cases) is what is pretty annoying too.

And I can't seem to pinpoint correlation between values in database and cases where arrow is visible in class diagram.

Whatever I tried to change, I couldn't properly fix it (not to mention, I can't re-produce it at will on new class diagrams).


Mario.

[Paolo F Cantoni]

But as you ask, Geert, why change?  Well, the reason would appear to be that they are now able to include an extrinsic value "Navigable=Unspecified".  This is not possible where SourceIsNavigable and DestIsNavigable are boolean values.

One would think that, but if I look into my database, I find values.

* 1 => Navigable
* 0 => Unspecified
* -1 => Not Navigable

I really don't see why they would want to move from a clearly defined normalised scheme to a scheme that relies on descriptions somewhere in a text field.

Geert

My Bad, I was looking at the original .eapx repositories where they are Yes/No (boolean) values.  I see the SQL Server columns are int columns.  Nothing like consistency! 
Since we have NO Not Navigable ends in our repository at the moment (we're only interested in the Navigable ends.  For us, unspecified => non-navigable), I didn't see them.

Your last point above is EVEN more apposite!

Paolo

[mariop]

Instead they are updating the SourceStyle and DestStyle columns and adding another key-value pair like: "Navigable=Non-Navigable;"

Geert

I see diff between one with arrow (19382) and one without it (19381). How it came to this, I have no idea. How to reproduce - no idea.

Mario.

[mariop]

Hi,

What can be concluded from this example? To file a bug? Or is it a feature? Maybe just very loose definition?

At the end, I would like to ditch those few arrows apearing in class diragram in EA16.

Thanks!

Mario.

[Guillaume]

This is not an official patch, but it might help you. Please backup your project before running the patch.

HTH,

I was never aware of this possibility to run a patch. I did these running a script with said precautions (sandbox, backup, etc.). Anyhow, is this something official or just leakage?

q.

Very interesting. I also never heard of this before, yet I found it in the online help (without any example): https://sparxsystems.com/enterprise_architect_user_guide/16.0/the_model_repository/runningsqlpatches.html
The effort seems to be the same as writing a script, but I can see the advantage in not deliver a script for patch purposes that could remain in the EA project. A typical scenario is deleting or renaming tagged values in the MDG stereotype definition, and updating the existing stereotyped elements or attributes.
Thanks for the info Takeshi 

[Geert Bellekens]

On very rare occasions Sparx has released a patch in the past.

I think I remember only one such occasion in the last 15 years.

Geert

[qwerty]

Thanks for the info Takeshi 

Well, seems he has removed the post meanwhile. So it was a leak, I guess.

@Geert: you don't happen to have kept that single patch (I can't remember ever having seen one)?

q.