mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-08-22 08:34:12 +02:00
ispyisail
43da912aad
Slice 2 of discussion #503 (from-to wiring list built on projectDataBase), building on the conductor uuid from slice 1 (#625). Pure plumbing: two new additive tables plus their populate/add/remove hooks. No view, no UI, no visible behavior change yet -- the wiring-list view is slice 3. Follows the existing shape of the class throughout: same table/column naming, same prepared-statement idiom in prepareQuery(), same bind/exec/qDebug-lastError error handling, same DELETE-then-loop populate pattern. - `terminal (uuid, element_uuid, name)` and `conductor (uuid, diagram_uuid, terminal1_uuid, terminal1_element_uuid, terminal2_uuid, terminal2_element_uuid, text)` created alongside the existing tables in createDataBase(). - populateConductorTable() added as a fifth populate* call in updateDB(). Terminal population is folded into it, since a terminal only matters here in the context of a conductor referencing it. - addConductor()/removeConductor() hooked into the already-existing Conductor::Type branch of Diagram::addItem()/removeItem(), mirroring the Element::Type branch directly above. Two things the original schema sketch in the discussion got wrong, found by testing rather than inspection: 1. Terminal::uuid() is NOT unique per placed terminal. It is the terminal-position id baked into the catalog .elmt definition ("the top terminal"), so every placed instance of the same catalog element shares it. A terminal instance is only uniquely identified by (uuid, element_uuid) together, so that pair is the terminal table's primary key and the conductor table carries both halves for each endpoint. With uuid alone as PK, the second placed instance of any element silently lost its terminals to the INSERT OR IGNORE. 2. Conductors whose terminals predate terminal uuids are omitted rather than given a fabricated identity, as agreed in the discussion. This turns out to matter far more than expected in practice -- see below. Testing (all live, in the running app): - Incremental add: fresh project, two vertically aligned contacts placed so autoconnect creates a conductor -> 2 terminals, 1 conductor. - Incremental remove: deleting that conductor -> conductor count 1 -> 0. - Undo: ctrl+Z after the delete -> back to 1, no duplicate-primary-key error (the same Conductor object keeps its uuid). - Bulk populate: examples/weneedpolonez-Polonez_MR89_wiring_diagram.qet (366 conductors) -> 478 terminals, 280 conductors; the 86 conductors touching legacy terminals correctly omitted. - Join correctness: conductor -> terminal (composite key) -> element_info resolves real from-to rows with real element labels. - Legacy-only project: examples/industrial.qet has 1794 terminals and *zero* terminal uuids, so all 671 of its conductors are omitted. Loads and renders fine, no crash, no spurious rows -- but worth stating plainly that a from-to wiring list for that project would be empty today. This is a property of the element catalog definitions, not of the project file, and is the strongest argument for surfacing an "N conductors excluded" count to the user when the view lands. - No SQL errors logged in any of the above. Known limitation, consistent with existing behavior: removeDiagram() does not cascade-delete the conductor rows of that diagram, exactly as it already does not cascade to element/element_info. A full updateDB() rebuild clears them, and the future wiring-list view INNER JOINs from conductor, so orphan terminal rows never surface.