-
Notifications
You must be signed in to change notification settings - Fork 3
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
Feature/mc 9631 - Branch and merge Model Data Type #223
Conversation
aaronforshaw
commented
Dec 22, 2021
•
edited
edited
- Fix bugs in the path retrieval of VersionedFolder.
- Add a method to the PathService to find a resource by its Path only, with no security check on the securable resource which owns the resource.
- When branching a Versioned Folder, update Model Data Types in the branched folder so that they point to the branched model.
- Update ModelDataType.diff so that it only returns a diff if the paths of the pointed to resource in source and target are different after ignoring differences in the branch and version. The diff returned is on 'modelResourcePath' rather than modelResourceId and modelResourceDomainType. This 'modelResourcePath' is computed as a fully qualified path by recursing up all parents of the model.
- Add a method to DomainService which enables subclasses to state that they will provide special handling for the patching a modification into a Versioned Folder
- In ModelDataTypeService, override the above method and use the 'modelResourcePath' provided in the diff to look up the relevant resource to point to when merging.
- Ditto the above two points, but for merging when not in a Versioned Folder
- Add test data
- Add tests for (i) branching of Model Data Type in a VF (ii) merge a Model Data Type when it is pointing to a resource in the source folder (iii) merge a Model Data Type when it is pointing to a resource outside of the VF
- Add test for branching and merging of a Data Model containing a Model Data Type when not in a VF
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.
Looks like the methodology is right,
All the stuff in path and path node and model, can you replace it all with the use of boolean matchesIdentifier(PathNode otherPathNode, String modelIdentifierOverride = null)
as thats why that method exists, you can pass in a branch name or model version number as the override and it will do everything you've coded up for you.
...ils-app/domain/uk/ac/ox/softeng/maurodatamapper/datamodel/item/datatype/ModelDataType.groovy
Outdated
Show resolved
Hide resolved
...ils-app/domain/uk/ac/ox/softeng/maurodatamapper/datamodel/item/datatype/ModelDataType.groovy
Outdated
Show resolved
Hide resolved
mdm-core/src/main/groovy/uk/ac/ox/softeng/maurodatamapper/core/model/ModelService.groovy
Outdated
Show resolved
Hide resolved
e2b4e2b
to
7cadf85
Compare
@olliefreeman Please see updated description at the top of this PR. |
…r than model identifier
…s in an external non-versioned folder
…ModelPluginMergeBuilder
35e29cb
to
0b811e8
Compare
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.
with the changes in commit im happy with this now
* Remove the addtl methods into CreatorAware as these already exist as part of PathNode where a pathnode can be altered using a modelIdentifier, this reduces the number of places where changes need to be made if we alter anything * Remove the coding relience on the concept of VFs, rather have one method for patch handling which uses the target to determine what happens. Allows for greater depth if we need to add any addtl handling later * MDTs are always keyed to models so use ModelServices list rather thae DomainServices list as its less to search and therefore faster * Make a handy method which can extract a model for a MDT or throw an exception thereby reducing the code needed
9250a3c
to
c768226
Compare
failing test is a known flaky test so merging |