Closed MichaelBelousov closed 1 year ago
my intended solution is to deprecate the json property targetRelInstanceId
and in lieu of it introduce provenanceRelInstanceId
. Which will always point to the relationship in provenanceDb
. We will handle the old case by finding the end elements of the relationship in the source, and then seeing if an equivalent relationship exists between the target's version of those elements.
the solution for this is now implemented in the federation-guid-optimization
branch
The way we currently set the
targetRelInstanceId
json property on external source aspects during branch workflows loses the information on which relationship was transformed during reverse-synchronization of deletes. I think this one is easier to visualize:In
packages/transformer/src/IModelTransformer.ts
, inIModelTransformer.initRelationshipProvenance
we store provenance like:Note that if created in a reverse-synchronization, the aspect $A$ placed on the relationship (technically on its source element) in the provenance-owning database ($B$ for Branch) does not have any links back to the relationship in the branch $R_b$. So if later $M$ deletes $R_m$, and we want to forward synchronize that deletion back into $B$, then we can't find $R_b$ directly.
Instead we probably have to find the source and target elements of $R_m$ and read the mapping of those into $B$ to find $R_b$.
Federation guid provenance doesn't have this issue.
forward sync graph dot code
reverse sync graph dot code