mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-09-28 04:54:13 +02:00
ispyisail
e3cb994e0e
removeDiagram() only ever deleted the diagram's own row. No foreign key in this schema is declared ON DELETE CASCADE (and SQLite foreign-key enforcement is never turned on for this connection anyway), so removing a diagram left every element, element_info, terminal and conductor row that belonged to it behind in the database -- silently, since nothing reads them until the next full updateDB() rebuild papers over it. Traced why this had never crashed anything: Diagram::~Diagram() explicitly walks and deletes its top-level items through removeItem() (which does call dataBase()->removeElement() correctly), but deliberately skips conductors -- because a conductor's destructor touches both of its terminals (terminal1->removeConductor(this)), and those terminals may belong to an element already destroyed earlier in the same sweep. Conductors are instead destroyed as a side effect of Terminal::~Terminal()'s qDeleteAll() on its own conductor list, which is a plain C++ delete that never goes through Diagram::removeItem() and therefore never calls dataBase()->removeConductor() at all. So the object graph is torn down safely, but the database is never told about the conductors or their terminals. Fixed by adding the missing bulk deletes to projectDataBase::removeDiagram() itself, run while the diagram (and its live scene) still exist -- verified that QETProject::detachDiagram() emits diagramRemoved() (which this class's constructor connects to this slot) synchronously, before the Diagram object is scheduled for destruction via deleteLater(), so nothing here races the C++ teardown described above. Order matters: element_info and terminal have no diagram_uuid column of their own, so both are scoped through a subquery on element and must run before element itself is deleted. Verified against examples/industrial.qet (50 diagrams) by calling projectDataBase::removeDiagram() directly and comparing table counts before and after, with no intervening updateDB() call to mask a gap: element=354->335 element_info=354->335 terminal=1087->1033 conductor=671->626 diagram=50->49 Every delta matches a direct SQL count for that diagram's own rows exactly (19 elements, 54 terminals), and both "orphan rows still referencing the removed diagram" checks read 0 afterward -- so the cascade is complete and, just as importantly, scoped: nothing belonging to the other 49 diagrams moved. Separate finding, not fixed here: QETProject::removeDiagram(Diagram*) (the synchronous, non-undoable variant, not the usual GUI ProjectView::removeDiagram() path) segfaults if the enclosing QETProject is destroyed before an event loop iteration lets its pending deleteLater() run -- reproduces identically on unmodified master, so it predates and is unrelated to this change. Worth its own report; a headless caller is the only realistic way to hit it, which is how this surfaced. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>