View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005826 | CaseTalk Modeler | Other | public | 2026-07-29 13:10 | 2026-07-29 13:11 |
| Reporter | Marco Wobben | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Target Version | 15.0 | Fixed in Version | 15.0 | ||
| Summary | 0005826: Saving a population registers phantom tuple records on label types | ||||
| Description | When a population row is stored, an extra tuple record is registered on one of the label types that appear in the expression, instead of on the fact type that owns the tuple. The population itself stays correct: the values in the population editor, the verbalizations and every report keep showing exactly what was entered. What goes wrong is the bookkeeping alongside it. Label types never carry a population of their own, so every one of these records is a phantom. The effect builds up over time. Each saved row adds another record, models carry a growing trail of tuples on label types, the tuple numbering of those label types is inflated, and anything that reads tuple administration (confirmation state, counter-example marking, tuple annotations) has to look past entries that do not correspond to anything in the model. Existing models already contain these records and need to be cleaned up when they are opened. | ||||
| Tags | No tags attached. | ||||
| CaseTalk Edition | Corporate | ||||
|
Tuples are now registered on the fact type that owns the expression, so saving a population no longer leaves records behind on label types. Models that already carry these phantom records are repaired automatically: when a model is opened, the tuple administration is reconciled with the population itself in both directions - a tuple that is missing for existing population values is created, and a tuple record that no population value backs is removed. Nothing in the population, the verbalizations or the reports changes; only the bookkeeping alongside it is brought back in line. |
|
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-07-29 13:10 | Marco Wobben | New Issue | |
| 2026-07-29 13:11 | Marco Wobben | Note Added: 0008710 | |
| 2026-07-29 13:11 | Marco Wobben | Status | new => resolved |
| 2026-07-29 13:11 | Marco Wobben | Resolution | open => fixed |
| 2026-07-29 13:11 | Marco Wobben | Fixed in Version | => 15.0 |