search

sageserpent-open / plutonium

CQRS providing bitemporal object modelling for Java POJOs and Scala too.
MIT License
5 stars 0 forks source link

Scaling - Spike - snapshot item state to avoid unnecessary patch application #29

Closed sageserpent-open closed 7 years ago

sageserpent-open commented 8 years ago

This is a prelude to issue #17 and #18.

Where patches need to be applied to reconstitute the state of an item in a scope, we can optimise this process by starting the patch playback from a related intermediate state that has already been calculated for some other revision / earlier business time.

sageserpent-open commented 8 years ago

The saved intermediate states of an item must be shallow - any references to related items should be converted into a marker that is reconstituted by fetching the related item by the existing mechanism for building / fetching an item. Having said that, it is important to ensure that when a snapshot is reconstituted, the states of any referenced items are those at the same revision / business time as the reconstituted item. It would be nice to then apply further patches to those referenced item as required elsewhere.

sageserpent-open commented 8 years ago

Hmmm - suppose I reconstitute item A that refers to item B, then apply some patches to A, then need to apply some more patches to B to get to the desired overall state for a scope. This is fine if B is patched from the same snapshot as was used to get B from the POV of A at reconstitution, but suppose another later snapshot of B is required to get the final form of B?

Either this would have to be disallowed, or we'd have to cutover A to refer to the new instance representing B, or we'd have to reconstitute the later snapshot of B into the same instance, or we'd have to have B being a proxy around the 'real' implementation that can be swapped out as required....

sageserpent-open commented 7 years ago

Story #37 will realise this, so closing this spike.