Uploaded image for project: 'Fluid Infusion'
  1. Fluid Infusion
  2. FLUID-5280

Clarify semantics for conflict resolution when attaching via model relay



    • Type: Improvement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 1.5
    • Fix Version/s: None
    • Component/s: Data Binder
    • Labels:


      The FLUID-3674 system now allows us to attach relays (transforming or non-transforming) between models, which relays act "instantaneously" on wiring up the model graph to bring it to a consistent condition by means of the "initial transaction". We managed to dodge some of the conflict resolutions inherent in this system by adopting the "transition to undefined" convention, that a model (or set of transforms) which holds or results in an undefined value is beaten by one which holds a defined one. However, we are quickly running into cases where genuine conflicts arise between two defined models.

      Together with the report for FLUID-5279 came a case with a supercomponent and a subcomponent with different model contents becoming relayed together. In this case, the supercomponent had explicitly modified its model since startup, and so created a clear expectation that its changes should trump those from the subcomponent which only arose through its defaults. This creates a reasonably clear path to create a "stopgap" solution without too much effort from our current implementation, based on "veterancy" - any model holding values from a component which is "completeOnInit" - that is, which is fully instantiated before the "initial transaction" begins to operate, should beat any model contents which arise from a component which is not complete in this way.

      It's really not clear what form a better solution to this problem might take, since this involves grappling with the problem of conflict resolution in all of its vast complexity. One possibility might be to allow an extra annotation on a relay indicating which direction will "win" in the case of an initial conflict. However, direct relays don't have a place to put such an annotation, and in general this option seems a bit crass. Another possibility might be to apply timestamps (or increasing tick numbers) to every change in the system, and allow any model with a later tick count to beat an earlier one. Models which were at their defaults (or statically distributed) states would be given infinitely old timestamps. However, this could open a huge can of worms in the case of composite models - there might be grounds for considering that different sections of a model should be assigned different ages according to the time they were modified. This would either require a lot more complexity in the change application process to track provenance, or else the revival of the "change bottling system" that we hoped we had left behind with the obsolete "video player relay" system.

      In truly ambiguous cases (for example conflicts between default initial values) the system should probably signal an error.

      We'll implement the "veterancy" system for now and keep thinking about alternatives.


          Issue Links



              antranig Antranig Basman
              antranig Antranig Basman
              0 Vote for this issue
              4 Start watching this issue