nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Uniqueness mediniIdentifier

medini_1052680584

Dear ANSYS team,

Is it safe to assume that each element in medini has

an unique mediniIdentifier property?

That is, if two elements are different, they have different mediniIdentifiers?

Thanks!

Cheers, Andre

Find more posts tagged with

medini

medini legacy

Accepted answers

medini_1024169437

Hi Andre,

that's a fair assumption you can make, however, a few remarks:

identifiers are NOT GUIDs, so not globally unique, only within a medini project
some connectors may violate this rule when they use external identifiers as medini identifiers, for example the DOORS classic connector is doing so I think, so if you import the same module twice into medini, you may have duplicates. So uniqueness is guaranteed within a model

Hope that helps

Jan

All comments

medini_1024169437

Hi Andre,

that's a fair assumption you can make, however, a few remarks:

identifiers are NOT GUIDs, so not globally unique, only within a medini project
some connectors may violate this rule when they use external identifiers as medini identifiers, for example the DOORS classic connector is doing so I think, so if you import the same module twice into medini, you may have duplicates. So uniqueness is guaranteed within a model

Hope that helps

Jan

medini_1052680584

Hi Jan,

Thanks for the prompt reply. That helped a lot!

Cheers, Andre

medini_1036016653

A think, that I have wondered before: Can the mediniIdentifier be set from a script? Background of my question: We generate parts of our model by scripts and recreation of these parts always show up as differences in Diff&merge. While I had asked in the past to optionally suspend the checking of mediniIdentifier, this seems to not be considered for implementation. Consequently, we could get around this by manually setting a hand-generated identifier for these objects.

medini_1024169437

Peter, you technically can set a medini identifier in a script (its a normal attribute). however, the script is responsible to make sure the id is indeed unique.

If you assign the same identifier twice the result is unpredictable.

We are currently working on a dedicated feature that allows users to only concentrate on the import script but not on the other parts as re-import (diff/merge) or loading of the model.

Once this is ready (most likely an update site) I will post something here.

Jan

medini_1036016653

Thank you for the immediate response and outlook. In case you need feedback on use-cases I have in mind, feel free to reach out.

medini_1024169437

Sure, thanks Peter. One think we are not yet 100% sure is indeed the way and API we need to offer to a script to create *safe* unique identifiers

that are specific to a certain technology. For Capella for example (one of the initial supported import formats) it might be okay to just use the EMF IDs

from Capella also in medini, for Excel (second supported importer) it may need a combination of a sheet/row/column or a specific cell content.

So if you have any idea here, please post it. The first version will not have any specific id support though I think.

Jan

medini_1058135173

Sorry, to dig out this old thread again but I stumbled upon the assumed "uniqueness" in 2022R1.

When I derive a variant of a "System/Function Model" via context menu "Derive->Variant", the model itself gets a new mediniIdentifier but all containing elements share the same mediniIdentifier with the source model. Even if I change the name/label of an element in the derived model, the mediniIdentifier is kept, thus having two different elements in my Medini project carrying the same mediniIdentifier.

Is this a recent bug? Up to today I assumed that the mediniIdentifier is also used during compare/merge operations and I use it in scripts the reliably find an element again if it has been moved or renamed.

Kind regards,

Stefan

medini_1024169437

No problem Stefan, I think you indeed stumbled over a special case )besides the cases mentioned above with sysml importers).

This is not a (recent) bug but instead a rather old feature that may violate the mentione duniqueness rule in the project, so its only unique in a model.

Jan

medini_1058135173

What does the compare/merge operation use then for identification of changed elements? Is there any other (really) unique identifier scripting has access to? Isn't there any GUID from the backend database?

My workaround would now be to create new (unique) mediniIdentifiers for all contained objects after a model variant has been derived. Are there any doubts going this way?

Stefan

medini_1024169437

Sorry Stefan for late reply,

well, compare/merge has different matching rules, first on resource/model level, than inside the model (where IDs are unique).

Variants are really special as they have intentionally the same ID.

If you combine the ID of the model proxy and the ID of the element, that should be unique.

I am not sure about the creation of new IDs, its not forbidden though. You may try suffix/prefix the ID to keep the original..

Note that we move away from local file system to a server in mid term, and this will change ID handling completely.

(there is no backend DB yet as we are solely file based).

Regards

Jan