uha4
c0dd24b6c5
- create_dataset.py, compare_snapshots.py, rst_to_dataset.py: Proteus- Testdatensatz anlegen/vergleichen bzw. aus *.rst-Szenarien extrahieren - create_dataset.py: Feld-Alias-Fallback (FIELD_RENAMES) für bekannte Umbenennungen wie stock.move.uom -> unit, bidirektional - merge_dedup_rsts.py: Extrahierte YAMLs pro Version zusammenführen, versionsinterne Duplikate entfernen, abhängigkeitskorrekt sortieren - extract_model_tree.py: Modellbaum (Modelle/Felder) statisch aus dem Tryton-Quellcode ziehen, für 5.0 und 8.0 - model_diff.py, model_coverage.py: 5.0<->8.0-Modelländerungen finden und gegen die aktuelle Testdatenabdeckung abgleichen, priorisiert nach tatsächlicher Änderung - reports/*_merged.yaml: Extraktionsergebnisse für die aktiven Module (rohe *.rst-Quellen bewusst nicht mitversioniert) - Ordner doc ergänzt
1.2 KiB
1.2 KiB
Datenbankmigration von 5.0 auf 8.0
Ziel: verstehen, wie sich das Datenbankschema der aktiven Tryton-Module über die Versionen 5.0 bis 8.0 verändert, als Vorbereitung für die eigentliche Migration. Zwei sich ergänzende Ansätze:
- doc/UPDATEANALYSE.md – Codeanalyse des
Updatemechanismus: statischer Scan der
__register__-Methoden aller Module über alle Versions-Branches hinweg. (fertig) - doc/TESTDATEN.md – Unterschiede im Zustand
erkennen, nachdem in zwei frisch installierten Versionen dieselben
Testdaten per Proteus angelegt wurden (Snapshot- und später
SQL-Dump-Vergleich). (in Arbeit - siehe Stand im Dokument)
- dazu als Vorarbeit: doc/MODELLVERGLEICH.md – welche Modelle/Felder gibt es je Version überhaupt, und wo hat sich zwischen 5.0 und 8.0 tatsächlich etwas geändert (steuert, wo sich Testdaten-Aufwand lohnt).
Eigene, von den Standardmodulen abweichende Module (production,
stock_product_location, stock_split, stock_lot_sequence) sind
bewusst noch nicht Teil dieser Analyse - erst wenn die Standardmodule
migrierbar sind, werden diese auf 8.0 portiert und die Testdaten-Pipeline
darauf erweitert.