search

vitruv-tools / Vitruv-DSLs

Languages for Specifying Consistency Preservation Rules
Eclipse Public License 1.0
2 stars 4 forks source link

Make `EChange` generic over its content type #90

Closed JanWittler closed 1 year ago

JanWittler commented 1 year ago

Adapts to https://github.com/vitruv-tools/Vitruv-Change/issues/59

There are some EChanges like InsertEReference that had two type parameters for their affected and new element. These had to be merged to one parameter such that there cannot occur a collision when conforming to the same EChange<Element> type. As such, explicit generic type annotations and typecasts had to be added to the code annotation

JanWittler commented 1 year ago

It seems that the Reactions produce an incomplete change sequence. Explicit unregistration in UuidResolver on element deletion works for the change and framework repositories but fails for the Reactions with the problem that some element was not unregistered at the end of a transaction. I would assume it relates to cascade deletion (https://github.com/vitruv-tools/Vitruv-Change/pull/48) but wasn't yet able to debug it.

As such, the UuidResolver does not enforce element unregistration. https://github.com/vitruv-tools/Vitruv-Change/blob/672e1a054be385534b15056d827a1f39a047b9a3/bundles/tools.vitruv.change.atomic/src/tools/vitruv/change/atomic/uuid/UuidResolverImpl.java#L207-L210