Data model review (2026-10-17)#

A review of the data the program keeps — the line model (ohl-line), the project file (ohl-session), OHL XML and the library formats — after the points-and-objects work. It says what holds up, what is broken, and what is worth changing, most urgent first. §1 to §4 were carried out (marked ✓; how, in Carried out). The data model map describes the model as it is.

What holds up#

• One line model, many stores. The line file, OHL XML and the project rows carry the same ohl_line::Line; OHL XML destructures every struct, so a new field cannot be forgotten silently, and it round-trips everything (spacers, taps, span and jumper points, objects, spreads, defaults, solver options, plugin values).
• Every change goes through commands, validated on the whole line, logged with its inverse, undoable; deletions list what goes with them.
• Old files keep opening: serde conversions (SectionFile, StructureFile, v1 attachments, v2/v3 routes) upgrade them on reading.
• Structures as explicit graphs (points, strings, wire points with sets) and points with one object (body or clamp) are general enough for what is planned (V + I, TAKs, taps, spacers).
• Library ids are the only cross-file references; units are SI inside, and the formats are versioned with a header.

1. Broken today (small fixes, no change to the model) — fixed#

All seven fixed on 2026-10-17 (tests in ohl-line and ohl-session). Opening a project now drops stale circuit starts; a project or line file with a span point's distance beyond its span, repeated spread labels or impossible stringing values is refused on opening (none were found in the lines checked). The Live fix marks every section when the line settings the solve reads change, and Live::set_library solves again with an edited cable library.

2. Inconsistencies in the model (format changes — to decide)#

These change the line file (a new version, older files still read).

3. The project file#

4. Library and exchange formats#

Carried out#

On 2026-10-17, each step its own commit, the line file now version 5:

• §1 all seven fixed, as proposed.
• 2.1 JumperEnd (a wire point or a tap) for from / to; version 4 from_tap / to_tap read.
• 2.2 spans stay referenced by index, moved in one place: Section::set_points (span points, the sagged span, clipped lengths), used by the section editor. Naming spans by their back structure was left: it breaks when a structure is put in a span the same way, and the index stays the simplest form for files.
• 2.3 supports are jumper points holding a clamp with a hold (a structure's strings, or a string from a point); Jumper::supports() / support() give the solver what it took before (results unchanged). The solver still has its two paths (a string from a point, a structure's strings): the placement is one, the mechanics differ.
• 2.4 SpanPlace / JumperPlace are enums; several keys in older files read by the old priority.
• 2.5 a spacer's ends must hold a clamp; bare ends of older files get a clamp of no weight when read.
• 2.6 rename_point (session) / Line::relabel_point; the Span points table relabels with it.
• 2.7 SpanLoad / SpreadLoad moved to ohl_line::legacy (read only); the working form is objects::SpreadStretch. Line.alignment and Route.legacy_* stay where they are: turning them into routes needs the whole line (Line::upgrade_routes), not one route's file form.
• 2.8 Defaults::PROGRAM by name; one insulator EA constant.
• 2.9 kept: colours by phase label, by system through the system's own colour.
• 2.10 Section.circuit → circuit_name (circuit still read).
• 2.11 Calculation { condition, method }, written as before.
• 2.12 version 5.

Then §4:

• 4.1 ohl_core::units::si reads plain f64 fields from a number (SI) or text with a unit; .ohlload takes units (its templates are written so), a galloping tilt angle text. Prices and _kv keys keep their unit in the file's currency or the key's name.
• 4.2 every header through check_header (both optional, newer refused), the six copies gone.
• 4.3 a mistyped key refused everywhere — .ohlload and objects on points were the ones letting typos through (a flattened shape); a test checks every library format.
• 4.4 *_FILE_FORMAT / *_FILE_VERSION / *_FILE_EXTENSION in each crate, used for every extension.
• 4.5 example insulators shipped (libraries/insulators); the structure-type and clearance-rule folders no longer looked for (they belong to a project and to a design code).
• 4.6 the example lines written at version 5 (their version 2 form kept as test data, read to the same line); an .ohlfe example; the XSD says its version is the line file's. A JSON Schema stays for .ohlw only.

Found on the way and fixed: turning a jumper along its circuit now turns all its points' places (only its supports were turned, and a tap end stayed at its old end); the clearance check took every clamp on a span as a tap (a spacer's clamp would have hidden the wire near it).

Then §3:

• 3.1 kept: points and spreads stay in their section's row (one designer per section).
• 3.2 the line's settings are rows (systems, solver, defaults, …); a change puts only the rows that differ, so two users keep both.
• 3.3 library files are objects of each project line (library rows), changed by logged, undoable commands; schema 4.
• 3.4 clearance rules, galloping, ambient cases, unit costs, poles and structure models are library kinds (rules, galloping, ambient, costs, poles, femodels): copied in from next to the project (poles and models from its structure folder) when it opens, read from the project after, kept per project line. The app's windows read the project's copies; the clearance zone windows save their rule files into it.
• 3.5 kept: a rename is a put and a delete.
• 3.6 replace_line keeps the replacing line's order.
• 3.7 spacers in the spatial index; jumpers with their taps.
• 3.8 the upgrade steps of older files in one place, in schema order (upgrade_before_tables, then descriptions and library files); a new file gets none of them and no legacy table (line_snapshot, library_file); an older file's are dropped once read.

Suggested order#

1. The fixes of §1 (carried out).
2. §2 (carried out, line file version 5).
3. §4 (carried out).
4. §3 (carried out).