In order to gain a better understanding of the level of effort and impact each option would have, we will create a prototype of the solution.
Timebox: 8 hrs?
From T403149: [MEX] M3.1.2 - Investigate options for improving information saved while publishing
Option 4:
- Teach EditEntity to respect the summary returned by ModifyEntity::applyChangeOp. At least in the most basic situations when an EditEntity API call boils down to a single ChangeOp with a single summary line. This is currently not easy to detect, unfortunately, but not hard to fix. Add a new method ChangeOp::isAtomic or ChangeOp::isSingular or similar and make non-atomic instances like the ChangeOps class return false (only when it really contains multiple), while all basic ChangeOp return true. Callers can use this information to decide which summary they should use.
- Implement and wire new ChangeOp instances for all the real-world situations you want to cover. These new classes would be rather short: All they do is to generate a nice summary specific to the use-case they are designed for. The actual changes are forwarded to any combination of existing ChangeOp classes (but their summaries are ignored). isAtomic would be true for these new ChangeOp instances because they are able to describe the change in a single, meaningful summary line.
- A good starting point is ChangeOpFingerprint. That would be a great place to detect and generate new summaries like "a label and a description in the same language changed". However, the class currently doesn't even try to generate a meaningful summary. Why is that?
To me this doesn't seem to be a larger change, unless I'm missing something.
As far as I understand the other proposals so far both option 1 and 2 have notable problems:
- Both suggest to analyze ChangeOpResult instances, not ChangeOps. But that's to late, isn't it? ChangeOpResult doesn't contain the information that would be needed to understand if a change can be described with a more narrow summary line. For example: What if a label and a description was changed the same time? If that happens often enough it could get a separate summary line. How would ChangeOpResult be able to understand that?
- Both proposals would generally re-implement something that already largely exists in the ChangeOp hierarchy. Why not just use the existing logic instead?