If an event encoding changes in client code, should Plutonium be responsible for dealing with this? I'm not sure if that question even makes sense, as the event would have been submitted to Plutonium as part of a revision, and can be corrected anyway if the encoding does change later.
If the client object model changes in a way that breaks binary compatibility, then Plutonium should detect that either its stored event patches or its item state blobs are no longer valid - but then what?
If the client model changes in a way that keeps binary compatibility buts breaks deserialization of the item state blobs, Plutonium could try to rebuild the timelines, using the stored event patches - in other works, do incremental recalculation from the broken blobs to rebuild them.
What would trigger such detection? Presumably failure to revise or to query - but should this simply be a detection followed by an explicit repair procedure, as one would want to sort out all broken blobs in a timeline, not just the odd one or two. Come to think of it, perhaps doing it per-blob on the fly is a good idea - incremental recalculation would probably fix lots of other damaged blobs into the bargain.
Should the repair apply to the latest revision and make a new revision, or should we be able to repair any existing revision, mutating the existing timeline for that revision?
This has three aspects:
If an event encoding changes in client code, should Plutonium be responsible for dealing with this? I'm not sure if that question even makes sense, as the event would have been submitted to Plutonium as part of a revision, and can be corrected anyway if the encoding does change later.
If the client object model changes in a way that breaks binary compatibility, then Plutonium should detect that either its stored event patches or its item state blobs are no longer valid - but then what?
If the client model changes in a way that keeps binary compatibility buts breaks deserialization of the item state blobs, Plutonium could try to rebuild the timelines, using the stored event patches - in other works, do incremental recalculation from the broken blobs to rebuild them.
What would trigger such detection? Presumably failure to revise or to query - but should this simply be a detection followed by an explicit repair procedure, as one would want to sort out all broken blobs in a timeline, not just the odd one or two. Come to think of it, perhaps doing it per-blob on the fly is a good idea - incremental recalculation would probably fix lots of other damaged blobs into the bargain.
Should the repair apply to the latest revision and make a new revision, or should we be able to repair any existing revision, mutating the existing timeline for that revision?