Skip to content

docs(intent): a re-parented child repairs both parents - #205

Merged
delchev merged 1 commit into
masterfrom
docs/rekey-both-sides
Aug 19, 2026
Merged

docs(intent): a re-parented child repairs both parents#205
delchev merged 1 commit into
masterfrom
docs/rekey-both-sides

Conversation

@delchev

@delchev delchev commented Aug 19, 2026

Copy link
Copy Markdown
Contributor

Documents the fix for dirigible#6819 on /help/intent/glue:

  • rollups — a fourth handler, RollupOnRekey, binds the child's -rekeyed topic, so the parent a child was moved AWAY from is corrected together with the one that received it, instead of waiting for an unrelated child of that parent to change.
  • The -rekeyed publish is no longer tied to the form submit. A targeted write — a process step's setRelationField, a resolves: lookup, a task form persisting what it edited — moves the same column and deliberately raises no -updated, so it publishes the previous AND the written row on -rekeyed: the only topic the roll-up / aggregate handlers subscribe to, which repairs both sides without re-firing every reaction bound to the record.
  • aggregates — same wording correction: the rekey handler is fed a row whose grouping moved, previous or written, not only the previous one.

Vendor-neutral counterparts: intent-specification#43, intentfile.github.io#34.

Roll-ups now generate a fourth handler on the child's -rekeyed topic, so the parent a child
was moved AWAY from is corrected with the one that received it instead of waiting for an
unrelated change. And the -rekeyed publish is no longer tied to the form submit: a targeted
write (a process step's setRelationField, a resolves: lookup, a task form) publishes both the
previous and the written row, which is the only signal either side gets on that path.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant