Standardize Merging - Logic, Approach, Testing

[kennethmorton]

With the addition of hashing and the update method this library can now be used as to combine or merge a set of messages. The logic for message merging should be agreed upon by all interested parties and validate through extensive testing. This issue is to hold such a discussion.

It is important that when we make decisions about how message merging will work, that the speed of the implementation is considered.

[kennethmorton]

To state initial objects:

Each TRAPI object may have a different set of criteria for how they are merged together.
The following should be guaranteed for all TRAPI object merges:

• Merging is symmetrical, so merge(m1, m2) == merge(m2, m1)
• Merging will raise errors iff provided values cannot be merged AND the provided values are different
• Some TRAPI objects allow extra properties. When these are present, they must all be identical for merging to be allowed

[kennethmorton]

The above may result sub-optimal speed. Consider these generic objects

QNode1: { “ids” : [], “deeply” : { “nested” : { “extra” : { “field” : {}}}} }
QNode2: { “ids” : [], “deeply” : { “nested” : { “extra” : { “field” : {“foo” : “bar”}}}} }

These two objects cannot be merged using the above criteria because of the mismatch of deeply.nested.extra.field. The only way to know that these objects cannot be merged is by traversing the object hierarchy and then identifying the mismatch.

[kennethmorton]

Restating objectives to more closely match the current implementation and provide a faster runtime.

Each TRAPI object has a different set of criteria for how they are merged together.
The following should be guaranteed for all TRAPI object merges:

• In the case of a conflict in merge(m1, m2), where conflict is any field for which no specified merging rule exists, the output value will be the value on m1. The only exception to this is if the value on m1 is null, in which case the value on m2 will be used.
• Because of the above property, merging is not guaranteed to be symmetrical, so merge(m1, m2) != merge(m2, m1)

Removing symmetry enables a faster implementation but may lead to inconsistencies. For example, if an ARS made several async requests to ARAs and merged the output. The order of that the responses are received can potentially impact that resulting merged message.