Solve Conflicts / Merger Refactor

[TestaDiRapa]

Scope of the PR

The current implementation of the automatic solve conflicts may lead to a loss of data (e.g. when merging different encryptedSelf fields). This PR changes this behaviour as follows:

Mergers

Merging will now be done through auto-generated merger classes, in a similar fashion of what is done on mappers. Each Merger exposes 2 methods:

• a canMerge methods that returns true if 2 objects can be merged without loss of information, and false otherwise
• a merge methods that merges the fields of 2 objects

The strategy to merge 2 fields or determine if they can be merged is the following:

• CanMerge:

  • If a merge strategy is defined on the param, it follows the rules defined by the merge strategy
  • If field is in identifier and does not have a merge strategy, then content equals
  • If is @mergeable → call inner Merger.canMerge() if both of them are non-null, else true
  • If is non @mergeable non-collection: either one of them is null or content equals
  • If is List/Set:
    • If inner type is @mergeable → call inner Merger.canMerge() comparing by the fields defined in the annotation (id by default)
    • If inner type is any-non collection → true
    • If inner type is collection → throw @ generation time (for now, but I don’t think we have that case)
  • If is Map:
    • If value is @mergeable → call inner merger on same key
    • If value is any-non collection → map is mergeable if keys are different or same keys have same values
    • If value is List/Set → delegate to list-set on same key

• Merge:

  • id and rev are always left (defined in the interface by annotation)
  • If a mergestrategy is defined on the property, use that
  • mergeable properties are delegated to the merger of the class
  • nullable non-collections will always be l ?: r
  • non-nullable non-collections MUST have a strategy defined
  • collections of mergeables will always use the mergeList/Set/Map method
  • other collection will aways be (r ?: emptyX()) + (l ?: emptyX())

Automatic Solve Conflcits

The automatic solve conflicts will solve the conflicts as long as the 2 revisions can be merged without loss of information. It may return a partial success or a failure as soon as it encounters a revision that cannot be merged.

New methods

New methods have been added to each controller to allow for a frontend-based merge resolution. In particular, there are 3 new methods for:

• get all the ids of entites with conflicts
• given an entity, get all the conflicts
• define a new entity that is the conflict winner, purging the other conflicting revisions