dohertj2/scadalink-design
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs(templates): record derive-on-compose decisions (naming, migration, tree UX)

Browse Source
This commit is contained in:
Joseph Doherty
2026-05-12 08:13:11 -04:00
parent 68548432b3
commit a968cefbc2
1 changed files with 22 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
docs/plans/2026-05-12-derive-on-compose-design.md
View File

@@ -243,30 +243,30 @@ Each phase is independently shippable and reviewable.
`ParentTemplateId`, but the UX hasn't been designed. `ParentTemplateId`, but the UX hasn't been designed.
- Cross-tenant template libraries. - Cross-tenant template libraries.
## Open questions ## Decisions
- **Derived-template names**: `Pump.TempSensor` vs `Pump_TempSensor` vs - **Naming**: dot-separated (`Pump.TempSensor`). Matches the canonical-path
`${parentName}::${instanceName}`? Visible only on the edit page since the format used in flattening. Visible in audit logs / error messages.
tree hides derived templates, but appears in audit logs and error messages. - **Delete base with derivatives**: block the delete and list the derivatives.
Default: dot-separated mirrors the canonical path format already used in User must remove or repoint them first.
flattening (`TempSensor.Temperature`). Pick this unless the dot is - **Migration of existing data**: EF Core migration on next startup
problematic for any existing pipeline. auto-derives every existing composition. After deploy all compositions are
derived; no mixed-mode code paths.
- **Tree UX**: derived templates hidden by default. "Show derived templates"
toggle on the tree page reveals them indented under their base. Always
reachable from the parent's Compositions tab.
- **Re-composing the same base in two slots on the same parent**: e.g., Pump ## Confirmed semantics
composes Sensor twice as `IntakeSensor` and `OutletSensor`. Two derived
templates: `Pump.IntakeSensor` and `Pump.OutletSensor`. Both inherit from
`Sensor`. Confirmed OK.
- **Composition order / dependency**: if the user composes A inside B and - **Re-composing the same base on the same parent in two slots** (e.g. Pump
later edits A's base — does B's derived template auto-pick up the changes? composes Sensor twice as `IntakeSensor` and `OutletSensor`) produces two
Answer per inheritance: yes for `IsInherited = true` fields, no for derived templates: `Pump.IntakeSensor` and `Pump.OutletSensor`, both
overrides. Aveva-consistent. inheriting from `Sensor`.
- **Cascade-delete confirmation**: deleting a base template that has - **Inheritance updates flow downward**: if a base attribute changes value
derivatives — block with a clear error listing the derivatives, force user later and the derivative has `IsInherited = true` for that attribute, the
to delete them first? Aveva blocks. Likely we should too. derived value updates. Once overridden (`IsInherited = false`), changes to
the base no longer affect that field.
- **Validation**: if base adds an attribute, derived inherits it on next load. - **Subsequent `LockedInDerived` after overrides exist**: surface as a
But what about derived overriding a field that base subsequently locks via validation error at deploy time; do not force-revert silently.
`LockedInDerived`? Force-revert the override on next deploy? Surface as a
validation error? Probably the latter.