dbinfrago / dbinfrago/py-capellambse
Offering a (semi-)automated way of fixing a corrupted Model (duplicated UUIDs)
- Dominant language
- Python
- Stars
- 72
- Forks
- 18
- Avg merge
- 2d 1h
- Merged PRs (30d)
- 1
Description
An [issue on the context-diagrams extension](https://github.com/DSD-DBS/py-capellambse/issues/153) should have been posted here. I tested the repair mechanism from Capella on our corrupted TestModel (from `856fb8e`) and it only did something to the `.aird` file.
For now dealing with duplicated UUIDs is to be done manually, by hand. In this issue we may find a way to automate fixing such models.
When checking out `856fb8e` and instantiating a MelodyModel instance one is greeted with:
`CorruptModelError: Duplicate UUID 'a7acb298-d14b-4707-a419-fea272434541' within fragment tests/data/melodymodel/5_2/Melody Model Test.capella`
In our easy case we deal with 2 functions with the same UUID `teach potions` and `Teaching`:


Now the `UUID` was involved in a FunctionChain:

and an allocation:

where the user should know which of the function was the right one for the FunctionalChain and allocation. In our case here we knew that `teach Potions` just needed a new `UUID`. After fixing this we then needed to deal with its port that also had the same UUID as the port of `Teaching`. It seems that `Teaching` was copied but without creating a new UUID for it via Capella. I know that our create API ([MelodyLoader.new_uuid](https://github.com/DSD-DBS/py-capellambse/blob/d61861e4c2547226ab8622ef560e75eb093f8909/capellambse/loader/core.py#L483)) did not cause this corruption.
From re-investigating this easy case again I see that there is already a decision to be made which requires artificial knowledge about the model content. That is why I'd say the maximum we could work on is an interactive stepper that assists the user on fixing the xml tree in the `.capella`, `.melodymodel` or even (god forbid) all `.fragment` files in the command line.
Contributor guide
Assessment
This issue has not been assessed yet.