proposal: a roll-up whose counted child is owned by another model - #56
Merged
Conversation
A `rollups:` entry requires the counted child to be declared in the same model as the parent whose field it maintains, which makes a natural total inexpressible whenever an n:m pairing puts the link rows in another module: the link entity lives with the document that owns one side of the pairing, while the other side's total belongs to the module that owns it. The proposal adds `model:` (the owner's `uses:` alias, as a cross-model schedule source already takes) plus `parent:` (the local entity the total lands on - authored, because a foreign child's relations are not in the document for `via` to be walked through), and states the edge rules: the parent must be local, the foreign properties are validated against the owner's model, the capacity guard cannot follow across the boundary, and which side of a re-parent is repaired.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Proposal
0028-cross-model-rollup-child.md.A
rollups:entry requires the counted child to be declared in the same model as the parent whose field it maintains. That makes a natural total inexpressible whenever an n:m pairing puts the link rows in another module - the link entity lives with the document that owns one side of the pairing, while the other side's total belongs to the module that owns it.The accounts-receivable shape: the invoice-side total over the allocation rows is expressible today (the allocation entity belongs to the invoicing model); the payment-side total over the same rows is not, so "is this payment fully applied?" and "how much credit is on account?" are answered by a report instead of by a stored, filterable number.
Adds
model:(the owner'suses:alias - as a cross-model schedule source already takes) plusparent:(the local entity the total lands on; authored rather than derived, because a foreign child's relations are not in the document forviato be walked through), and states the edge rules: the parent must be local, the foreignvia/of/byare validated against the owner's generated model and aviareferencing another entity is refused, the capacity guard cannot follow across the boundary while the balance and status can, which side of a re-parent is repaired, and that a restricted foreign field does not propagate its restriction.Reference implementation: eclipse-dirigible/dirigible#6932 (issue eclipse-dirigible/dirigible#6930).