tryton-db-migration/UPDATEANALYSE.md

Tryton DB-Migrationsanalyse (AST-Zweig)

Analysiert per statischem Code-Scan, welche Datenbank-Operationen die __register__-Methoden aller Tryton-Module über mehrere Versionen hinweg ausführen – ohne die Module tatsächlich zu installieren/upzudaten.

Workflow

./run.sh

Checkt der Reihe nach jeden Versions-Branch (5.0 bis 8.0) im Tryton-Repo aus, lässt extract.py pro Version über alle konfigurierten Module laufen (Ergebnis: data/<version>/<modul>.json), und ruft danach compare.py auf, das daraus die aggregierten Reports in reports/*.md erzeugt (ein Report pro Modul, gegliedert nach Tabelle und Version).

Einzeln aufrufbar:

python3 extract.py --repo <pfad-zum-tryton-clone> --output data
python3 compare.py

Was extract.py erkennt

• Erkannte DB-Operationen (column_rename, add_column, update, insert, execute, ... – siehe INTERESTING_OPS) inkl. Tabelle(n), Zeile, Bedingung (if-Kontext), Phase (before_super/after_super).
• Steigt in for/while/with/try ab (nicht nur if).
• Löst Aufrufe an Helper-Methoden derselben Klasse auf (cls._migrate_x(...)) und markiert die gefundenen Operationen mit "via": [{"method": ..., "line": ...}].
• Loggt alle sonstigen, nicht erkannten Aufrufe zusätzlich als "unresolved": true – Rohmaterial für die manuelle Sichtung, gefiltert um bekanntes Rauschen (Pool(), Transaction(), cursor, .append, pool.get, logger.*, __table__/__table_handler__).

Was extract.py NICHT erkennt (bewusste Grenzen)

• Cross-Datei-Aufrufe: Ruft __register__ eine Funktion aus einem anderen Modul/Utility-Modul auf (z. B. migrate_property(...) aus trytond.model.modelstorage), wird das nicht verfolgt – landet als unresolved, der eigentliche DB-Zugriff bleibt unsichtbar.
• XML-Datendateien (ir.model.data) – bewusst ausgeklammert, da Konfigurationsdaten ohnehin manuell geprüft werden müssen.
• .sql-Dateien in Modulen – werden nicht gescannt.
• Implizite Schema-Änderungen durch reine Feldtyp-Änderungen im Python-Code (ohne expliziten add_column/alter_size-Aufruf).

compare.py – Aggregation & Dedup

Fasst pro Tabelle die Operationen aller Versionen zusammen und zeigt eine Operation nur dann erneut an, wenn sie sich vom tatsächlichen, vollständigen Bestand der unmittelbar vorherigen Version unterscheidet (nicht: irgendwann schon mal gesehen). Das behandelt korrekt sowohl den Normalfall (Migrationscode bleibt über viele Versionen unverändert – wird nur einmal angezeigt) als auch den Fall, dass ein Block zwischenzeitlich durch etwas anderes ersetzt und später identisch wieder eingeführt wird (taucht dann korrekt erneut auf).

Zeigt keine "wurde entfernt"-Markierung – nur Neues/Verändertes.

Konfiguration

• Modul-/Repo-Defaults: oben in extract.py (DEFAULT_REPO, DEFAULT_MODULES).
• Versions-Range: START/END in run.sh.
• Rauschfilter für unresolved: IGNORED_UNRESOLVED_* in extract.py – bei Bedarf erweitern, wenn sich beim Sichten neue, eindeutig irrelevante Muster zeigen (siehe Git-Historie für die bisherige Herleitung).

Nächster Schritt

Ergänzender, unabhängiger Zweig: Proteus-basierter Vergleich (echte Testdaten in zwei frisch installierten Versionen anlegen, Fehler/ Reformatierung erkennen) – siehe create_dataset.py, compare_snapshots.py, rst_to_dataset.py (Stand: ungetestet gegen echte Tryton-Instanz).