Inventarisatie DB tools

[tcdewit]

In deze issue zou ik graag de behoefte willen inventariseren naar tools/pagina's voor beheer/opschonen van de database. Idee is om dit onder het admin-menu te plaatsen. Enkele voorbeelden:

• alle resultaten van een bepaalde selector verwijderen
• iqc-database initialiseren naar de "fabrieksinstelling"

graag aanvullen!

[wadqc]

• verwijderen van studies / series zonder entry in de "gewenste processen" tabel. Deze studies hebben geen match met een selector gehad, er is dus geen analyse gedaan en er zijn geen resultaten. Betreft dikwijls (patient) data die per abuis de WAD server is ingeschoten. Voorstel: gegevens verwijderen uit tabellen collector_*_status, files, instance, series, study, patient. Voorwaarde: bijbehorende study moet eerst uit DCM4CHEE verwijderd worden door admin, anders staat ie er zo weer in. Dus: waarschuwing in webinterface genereren als de study nog in DCM4CHEE staat.

[tcdewit]

Zie eerste opzet in commit 215ef40a0085c61356a11d1fc078a133914961fa. Er zijn nu 3 acties geïmplementeerd; 2 zijn nog WIP. Het is niet moeilijk om daar acties aan toe te voegen, mochten er reacties bijkomen in deze issue-thread.

[wadqc]

Even snel getest: bij actie: verwijderen pat/studies/series zonder entry in gewenste processen tabel krijg ik deze foutmelding: "Fatal error: Call to a member function close() on a non-object in C:\WAD-software\WAD_Interface\website\WAD-IQC\database\iqc\beheer_db.php on line 510" Data is niet verwijderd.

[wadqc]

Lijkt me verstandig hier een tweetraps raket van te maken: dropdown box + een knop. Beetje gevaarlijk zo (ondanks rode tekst)

[wadqc]

Actie "verwijder alle resultaten voor specifieke selector" is blijkbaar een zware query, duurt nogal lang (proces mysql actief) en uiteindelijk melding: "Fatal error: Maximum execution time of 30 seconds exceeded in C:\WAD-software\WAD_Interface\website\WAD-IQC\database\iqc\beheer_db.php on line 259"

[tcdewit]

• Alle queries zijn momenteel een 2-trapsraket toch? Wat had je precies in gedachten?
• Mbt close() error: in laatste commit heb ik result_patient_dcm4chee->close() binnen de loop gezet, waar deze hoort. Dat zou het probleem moeten oplossen.
• trage query: dat komt vanwege het feit dat er momenteel per selector het aantal gewenste processen, floats, chars, etc wordt uitgerekend. Bij mij gaat dat op zich wel snel genoeg, maar blijkbaar niet bij een goed gevulde db (staat opmerking over in de code). De alternatieve query staat er ook al genoemd.

[tcdewit]

Om niet al het werk voor niets te laten zijn geweest.. zo had ie er uit moeten zien: ;-)

[wadqc]

• ik dacht dat er meteen een (delete) actie uitgezet werd, maar blijkbaar is trap 1 alleen een query. Sorry, had trap 2 nog niet gezien.
• close error opgelost voor pat/stu/ser maar nog niet voor stu/ser
• deze lijst met selectoren krijg ik inderdaad niet te zien

[tcdewit]

close() error is nu opgelost voor beide gevallen (bleek niet nodig gezien delete-stmt geen mysqli-object teruggeeft). Verder wordt nu ook daadwerkelijk gekeken naar de dcm4chee db; er werd per ongeluk nog steeds $link gebruikt ipv $link_dcm4chee.

[tcdewit]

Trage query is nu gefixt. Zijn naam en omschrijving genoeg? Of zijn er meerdere kolommen gewenst bij de "verwijder alle resultaten voor specifieke selector" query?

[wadqc]

Query is nu snel. Bij verwijderen resultaten selector kreeg is wel weer een time-out (30s), gedurende die tijd is proces mysqld actief. Bij 2e keer verwijderen (dus: herhaling opdracht) gaat het heel snel (1s). Gereproduceerd bij verwijderen resultaten andere selector. Eindresultaat is dus wel positief, maar opdracht moet twee keer gegeven worden. Aantal kolommen is wat mij betreft ok.

[wadqc]

Verwijderen resultaten selector: de staat van de database na deze actie is wel inconsistent lijkt me. Selector staat nog wel in de resultaten lijst, maar deze is leeg. Studies staan nog wel in de processor lijst, maar kunnen niet meer gestart worden (XML output mappen zijn weg, geeft fout van processor). Ideeen:

• selector zou niet getoond moeten worden in resultaten lijst. Dus dan moeten de entries uit de gewenste_processen lijst.
• XML output mappen zijn weg, dus de anaysemodule input file is ook niet valide. Ook verwijderen, plus bijbehorende entries in analysemodule_input/output.
• als vanuit die situatie de selector gereset wordt, dan denk ik dat er weer resultaten geproduceerd gaan worden.

[wadqc]

Verwijder gewenste processen zonder resultaten: query geeft: "Aantal gewenste processen zonder resultaten: 99". Vervolgens knop Go! geeft foutmelding:

         Error in executing delete resultaten_floating,resultaten_char,resultaten_object,resultaten_boolean from gewenste_processen left join resultaten_floating on gewenste_processen.pk=resultaten_floating.gewenste_processen_fk left join resultaten_char on gewenste_processen.pk=resultaten_char.gewenste_processen_fk left join resultaten_object on gewenste_processen.pk=resultaten_object.gewenste_processen_fk left join resultaten_boolean on gewenste_processen.pk=resultaten_boolean.gewenste_processen_fk where gewenste_processen.selector_fk in () stmt

        error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 11

[wadqc]

Verwijder pat/stu/ser en stu/ser zonder entry in gewenste processen: werkt. Van deze entries zouden er ook geen referenties in de analysemodule_input/output tabellen zijn. Bijbehorende referenties in de collector_study_status zie ik ook niet terug, dat klopt ook.

[tcdewit]

• Mbt trage/dubbele query: probleem is dat deze query helaas even duurt als er veel resultaten zijn. Dit is alleen op te lossen door de query op te knippen (bijv naar resultaat-type).
• Error bij de "Verwijder gewenste processen zonder resultaten": excuus... ik had wat code gecopy-paste maar de query-string verwijzing nog niet aangepast. Bij het testen had ik in eerste instantie debug-regels gebruikt ipv de daadwerkelijke queries. Is nu gefixt.
• gewenste processen entry wordt nu ook weggehaald bij de "verwijderen resultaten specifieke selector" query.

To Do:

• analysemodule_input/output entries weghalen bij meerdere queries zal ik nog implementeren. Het fysiek weghalen van de xml's zal ik dan ook meteen meenemen. Idealiter zouden we dit in de db moeten regelen middels "on delete cascade" maar ik weet niet of dit nu nog kan? De huidige "on delete cascade" fk-constraints zijn volgens mij niet erg zinvol geimplementeerd:

ALTER TABLE gewenste_processen ADD CONSTRAINT gewenste_processen_ibfk_1 FOREIGN KEY (analysemodule_input_fk) REFERENCES analysemodule_input (pk) ON DELETE CASCADE ON UPDATE CASCADE, ADD CONSTRAINT gewenste_processen_ibfk_2 FOREIGN KEY (analysemodule_output_fk) REFERENCES analysemodule_output (pk) ON DELETE CASCADE ON UPDATE CASCADE;

Bij weghalen van een analysemodule_input.pk zal het bijbehorende gewenste proces worden gedelete, terwijl dit juist andersom zou moeten.

[tcdewit]

Dit laatste is helaas vanwege de db structuur niet mogelijk (dan hadden de analysemodule_input/output tabellen namelijk fk's moeten bevatten naar de gewenste processen entries ipv andersom). In de code is dit op te lossen door per gewenst_proces.pk de bijbehorende analysemodule_input/output entries middels een delete-query te verwijderen. In de beheer-pagina zou ik daar ook nog een query voor kunnen toevoegen (entries in analysemodule_input/output tabel zonder bijbehorend gewenst proces).

[tcdewit]

Fysiek opschonen van de XML/analysemodule_input folder vanuit de webinterface is helaas niet mogelijk; althans niet op alle platforms, gezien deze door de Services worden aangemaakt (meestal een andere gebruiker dan de apache-user en dus andere permissies). Voorstel voor enhancement: een commandline tool die de xml's opschoont op basis van beschikbaarheid in de db.