Skip to content
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

Merged
merged 21 commits into from
Apr 5, 2023
Merged

Migrate to UUIDs #572

merged 21 commits into from
Apr 5, 2023

Conversation

JanWittler
Copy link
Contributor

@JanWittler JanWittler commented Nov 15, 2022

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.

  • Adapt to API changes
  • Rewrite 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.

Jan Wittler added 4 commits February 5, 2023 11:21
# 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
}
modelUris = Files.readAllLines(fileSystemLayout.getModelsNamesFilesPath()).stream().map(URI::createURI)
.toList();

} catch (NoSuchFileException e) {
// There are no existing models, so don't do anything
Copy link
Contributor

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?

Copy link
Contributor Author

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?)

@JanWittler JanWittler marked this pull request as ready for review April 5, 2023 07:52
@JanWittler JanWittler requested a review from a team as a code owner April 5, 2023 07:52
@TomWerm TomWerm merged commit 5d1ed7e into main Apr 5, 2023
@TomWerm TomWerm deleted the uuid branch April 5, 2023 09:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants