proposal: period locking - a record dated in a closed period becomes read-only - #55
Merged
Conversation
…read-only immutableWhen freezes a record for what it IS; this proposes the other axis - freezing it for WHEN it falls. Two declarations, because the two facts live in two places: a `period:` marker on the register (an ordinary entity with two dates and a lifecycle) names its bounds and what CLOSED means, and each guarded entity spends one line naming the register plus which of its own dates decides the window. Refs eclipse-dirigible/dirigible#6535. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
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.
immutableWhen:freezes a record for what it is - a journal entry stops being editable because its own status says POSTED. This proposes the other axis: freezing a record for when it falls. Once the accountant closes March, nothing dated in March may be created, edited or deleted, whatever status the individual record carries.Two declarations, because the two facts live in two places. A fiscal period is an ordinary entity - two dates and a lifecycle - so a
period: { start, end, closedWhen }marker on the register states what only the register knows, while each guarded entity spends one line:immutableInPeriod: { period: <Register>, date: <own date field> }. Which date counts (issue date / tax event date / posting date) is a modelling decision, so it is authored rather than inferred, and closing a period stays a plain status transition - nothing in the construct writes the register.The proposal covers the three ways this differs from the status guard (a create into a closed window is refused, an update that moves a record into one is refused, and a date covered by no period is open), how it composes with
immutableWhenand with a composition child's inherited lock, and the same-model boundary.Reference implementation: eclipse-dirigible/dirigible#6928. Filed from eclipse-dirigible/dirigible#6535.