Opened at 2010-03-09T04:50:53Z
Last modified at 2023-09-13T17:15:00Z
#569 new planned
persisted Session contents
| Reported by: | Ichthyostega | Owned by: | |
|---|---|---|---|
| Priority: | lesser | Milestone: | 1alpha |
| Component: | lumiera | Keywords: | FocusTopic session persistence design |
| Sub Tickets: | #214, #570, #578, #956, #1234 | Parent Tickets: | #76, #213 |
Description (last modified by )
As Lumiera Product Owner,
I want a generic scheme to represent session contents externally,
to be able to persist and re-load the complete contents of the Session, including future extensions.
Design, refactoring and consolidation work
Addressing this topic requires the foundation and outline of the high-level Model to be complete, and it also requires a workable concept regarding Event logging and Event sourcing. Which in turn requires to define the boundary between commands and events, and to resolve the tensions and problems arising from a rules-based configuration.
Essentially, it must be clear what (not) to persist, and in which form.
In its pure form, Event sourcing implies that the „concrete“ data model is merely a projection from re-playing the event log. A materialised snapshot of the current model can be used as a shortcut — but this bears the danger of capturing discrepancies and inconsistencies in the snapshot, which can not be reproduced by replaying the log; this danger can be mitigated by establishing test procedures to ensure any model state is always reproducible from the log.
Another challenging question arises from the integration of rules based configuration and resolution. Changing a rule can lead to unexpected and far-reaching ramifications, altering the arrangement and interpretation of session contents. Care has to be taken thusly to persist the actual cause, not some obviously given thing, which in fact is just a consequence of resolving rules. Logical imprecision bears the danger of introducing redundancy, leading to inconsistencies and unstable state later, especially when the event log is altered (and the ability to reorder and rewrite the log is a tenet of the event sourcing architecture). This challenge and possible danger is exacerbated by the fact, that configuration is layered and includes elements of generic defaults, system-wide setup and user specific customisation; what can be considered „an event“ under such circumstances?
Analysing and resolving these tensions is a cornerstone of this task regarding a persistent session. The user entrusts months of editing work into the persisted form of the session; what was settled once, must remain this way, reliably, whatever it takes.
Change history (4)
comment:1 by , at 2010-03-09T04:57:14Z
| blockedby: | → 570 |
|---|
comment:2 by , at 2023-09-12T01:29:36Z
| blockedby: | 570 → 214, 570, 578, 956 |
|---|---|
| blocking: | 213 → 76, 213 |
| Description: | modified (diff) |
| Keywords: | FocusTopic design added |
| Summary: | persist session contents → persisted Session contents |
comment:3 by , at 2023-09-13T17:15:00Z
| blockedby: | 214, 570, 578, 956 → 214, 570, 578, 956, 1234 |
|---|
comment:4 by , at 2025-12-25T00:00:00Z
| blockedby: | 214, 570, 578, 956, 1234 |
|---|---|
| blocking: | 76, 213 |
| Parent Tickets: | → 76, 213 |
| Sub Tickets: | → 214, 570, 578, 956, 1234 |

Migration MasterTickets ⟼ Subtickets-plugin