At the moment, at migrate time, there is a merge of the old and new properties helm by the instance. However, this merge of properties does not take account of nested maps that need to be recursively merged.
Solution 1
For any "property" of the new Map, recursive update will be apply only if in both new and old map, the type of the value "map.get(property)" are Map.
Type of oldMap.get(property) | Type of newMap.get(property) | Operation |
|---|---|---|
| int/string/boolean/list | Map | update |
| Map | int/string/boolean/list | update |
| int/string/boolean/list | int/string/boolean/list | update |
| Map | Map | recursive update |
Solution 2
The implementation of the recursive properties validation It could help for the recursive update. In order to apply the recursive update it needs to implement the recursive properties validation.
Using same methods for the validation, we can convert properly what is supposed to be a Map by definition.
...
- Create reusable methods to retrieve data structure of the properties
- Implement validation in creation, update and migrate of the instance
- Implement recursive merge and add eventually additional validations in migration
- participant needs same recursive merge, so needs the full service template in priming time
Unresolved question:
Note:
- We can do same implementation in update
- In solution 2, we can
- How is suppose to merge two data if the structure is defined differently into the two composition definitions? is the migration valid?
- Do we need same behavior in update functionality?
- Can we support default values defined into the composition definition?