-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate to UUIDs #572
Migrate to UUIDs #572
Conversation
...ests/src/tools/vitruv/framework/views/changederivation/BasicStateChangePropagationTest.xtend
Outdated
Show resolved
Hide resolved
copy UUIDs to identity view
adapt view tests to enforce non-null UUID resolver
…therwise transactions on the shared UUID resolver are ended before all IDs are assigned
…ith elements of the actually provided resource set instead of ones from the internally used resource set
# Conflicts: # bundles/tools.vitruv.framework.views/src/tools/vitruv/framework/views/changederivation/StateBasedChangeResolutionStrategy.xtend # bundles/tools.vitruv.framework.views/src/tools/vitruv/framework/views/impl/ChangeDerivingView.xtend # bundles/tools.vitruv.framework.views/src/tools/vitruv/framework/views/impl/ChangeRecordingView.xtend # bundles/tools.vitruv.framework.views/src/tools/vitruv/framework/views/impl/IdentityMappingViewType.xtend # tests/tools.vitruv.framework.views.tests/src/tools/vitruv/framework/views/changederivation/BasicStateChangePropagationTest.xtend # tests/tools.vitruv.framework.views.tests/src/tools/vitruv/framework/views/changederivation/StateChangePropagationTest.xtend # tests/tools.vitruv.framework.views.tests/src/tools/vitruv/framework/views/impl/ChangeDerivingViewTest.java # tests/tools.vitruv.framework.views.tests/src/tools/vitruv/framework/views/impl/IdentityMappingViewTypeTest.java
...ls.vitruv.framework.views/src/tools/vitruv/framework/views/impl/IdentityMappingViewType.java
Outdated
Show resolved
Hide resolved
...ls.vitruv.framework.views/src/tools/vitruv/framework/views/impl/IdentityMappingViewType.java
Outdated
Show resolved
Hide resolved
...ls.vitruv.framework.views/src/tools/vitruv/framework/views/impl/IdentityMappingViewType.java
Outdated
Show resolved
Hide resolved
...ools.vitruv.framework.vsum/src/tools/vitruv/framework/vsum/helper/VsumFileSystemLayout.xtend
Outdated
Show resolved
Hide resolved
} | ||
modelUris = Files.readAllLines(fileSystemLayout.getModelsNamesFilesPath()).stream().map(URI::createURI) | ||
.toList(); | ||
|
||
} catch (NoSuchFileException e) { | ||
// There are no existing models, so don't do anything |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just for clarification: There could be a case where the model is not saved and we want to read it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least when then repository is created initially, i.e. there are no repository files yet created, this could be the case. In any other case, I would expect an existing serialisation. (But this discussion is not really part of this PR, right?)
This PR migrates the V-SUM to use UUIDs within its changes while preserving hierarchical IDs for any view (adapting to vitruv-tools/Vitruv-Change#47). The conversion from HID-based changes to UUID-based ones happens in the
IdentityMappingViewType
.ResourceRepositoryImpl
to use one change recorder instead of multiple ones. I must admit that I don't fully recall why I added this change. I guess it was before I separated change recording and UUID assignment as sharing a UUID resolver over multiple recorders might be problematic. Anyways, it does not change functionality and makes the code easier to read, thus I would suggest to keep that change.There is one code duplication regarding assigning hierarchical IDs to changes. As we should refactor hierarchical ID and UUID resolvers to be hidden behind the same
IDResolver
interface I postponed refactoring this code smell to when such interface exists. I would document it accordingly in an issue.