Composition with direction arrow after migration from v14 to v16

[mariop]

Hi,

I am seeing some (not all, and that is annoying) compositions in v16 of diagrams having direction arrow. On same diagrams in v14 that is not the case.
I checked definition of relation and didn't find anything I could point at to be cause of it.

In this example in both cases direction is defined as: Source -> Destination.

It has to be something causing this. Anyone had something similar?


Original in v14:


Migrated in v16:

[Geert Bellekens]

If it's "Source -> Destination" then there should be an arrow. (and v14 is wrong in not showing the arrow)

If you don't want to show the arrow you can choose "Unspecified"

Geert

[mariop]

Hi,

Thanks for confirmation. I suspected it, but I am a bit confused - I see some similar with direction defined the same way with no arrow at all.

Example:

[Geert Bellekens]

Ah, but your second one is showing an Aggregation, is that the same for the relation between PartyAddress and Party, or is that an Association?

Geert

[mariop]

Hi,

It is the same relation type.

Properties for that one (the one with the arrow):


--
Mario.

[qwerty]

The direction for the other should be Unspecified. If not: report a bug.

q.

[Takeshi K]

Hi mariop,

I am sure that the drawing is affected by the following change in the Readme file of the version 16.

Improved the display of arrowheads on Aggregations and Compositions

In my some diagrams (basically made many years ago), I can see the same situation.
I think this is not a bug, but because of the bug fix. I think that the arrowheads should be shown naturally, but EA did not show the arrowheads as a bug in the older builds.

Anyway, fixing them manually one by one is crazy. I have made a patch file for Japanese customer like below. Save the XML as a file with 'xml' extension, then import it via Settings ribbon | Model | Integrity | Run Patch.

---
<?xml version="1.0" encoding="UTF-8"?>
<EAPatch>
    <EAPatch.content>
   <PatchDescription>This patch will remove arrows of Aggregations.</PatchDescription>
   <PatchQuery> SELECT Count(*) AS NumRecords FROM t_connector WHERE Direction = 'Source -> Destination' AND Connector_Type = 'Aggregation';
   </PatchQuery>
   <PatchSQL> UPDATE t_connector SET Direction = 'Unspecified', DestStyle = 'Union=0;Derived=0;AllowDuplicates=0;Owned=0;Navigable=Unspecified;' WHERE Direction = 'Source -> Destination' AND Connector_Type = 'Aggregation';
   </PatchSQL>
    </EAPatch.content>
</EAPatch>
---

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

HTH,

[Geert Bellekens]

I would report it as a bug because it's clearly inconsistent.

But in the end, if you don't want to see the arrows, you'll need to use "unspecified" as direction.

Geert

[mariop]

Hi,

Well, that is another thing: Arrow will not disapear with changing direction to "unspedified".




However, changing it to "Destination to Source" makes the arrow jump on left end (which is expected):


Something is fishy here. I am testing this on version 16.0.1605. (trial license).

[qwerty]

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.

[mariop]

Hi,

I checked in the database for two aggregations (one with mistery arrow, and one without it). When I change Deirection to "Unspecified", it gets changed in database properly, but in class diagram arrow remains.

Only for certain aggregations, though. I can't make it consistent, nor can I determinate what might cause this.
Looks like a bug, but unsure.

Best regards,

Mario.

[Geert Bellekens]

There are in fact three separate columns that determine the direction, so there is a chance that there is an internal inconsistency that causes this behavior.

- t_connector.Direction
- t_connector.SourceIsNavigable
- t_connector.DestIsNavigable

Maybe, if you are lucky, a project integrity check solves this.

Geert

[mariop]

Thanks for the tip. I will look into it.

I already ran project integrity check and fixed all issues at some point. No new issues atm (according to it).

Mario.

[mariop]

OK, here is example:


First one is without mistery arrow, second one is with it.
I see no difference (Direction won't fix it)

[Geert Bellekens]

The first one is correct, the second one is not correct.

If the direction is "Source -> Destination", then the DestIsNavigable should be 1

The Direction should really be a derived field based on the the values of SourceIsNavigable and DestIsNavigable.

Geert