Eine falsche Versionsmarkierung ablehnen

Eine Versionsmarkierung ist eine Aussage über die Struktur einer Datenbank. Teste eine ehrliche Datenbank der Version 1, die migriert werden soll, und eine Datenbank, deren Markierung Version 1 sagt, obwohl members.email bereits existiert.

Die neue Funktion auf Modulebene in tests/test_catalog.py ist mit genau dieser Schnittstelle vorgegeben:

write_version_one_database(database_path, include_email=False)

Sie öffnet den übergebenen Pfad, schreibt die unveränderlichen Tabellen und die Markierung der Version 1, fügt optional die abweichende E-Mail-Spalte hinzu, schreibt fest und schließt. Lass diese Funktion unverändert. Erstelle in test_schema_guard_checks_marker_and_shape(tmp_path) zwei Pfade und rufe sie genau wie folgt auf, bevor du die Einrichtungsschnittstelle ausführst:

write_version_one_database(exact_path)
write_version_one_database(mismatched_path, include_email=True)

Füge der exakt passenden Datenbank ein gewöhnliches Mitglied hinzu, schließe sie und rufe catalog_setup.prepare_database(exact_path) auf. Öffne erneut und verlange Version 2, die geordneten Mitgliederspalten mit email am Ende und das erhaltene Mitglied mit Python None in diesem neuen Feld.

Füge für den abweichenden Pfad ein Kontrollmitglied mit E-Mail hinzu und halte seine Version, geordneten Spalten und Zeilen fest. Rufe catalog_setup.prepare_database(mismatched_path) innerhalb von pytest.raises(ValueError) auf. Vergleiche die exakte Meldung Schema version 1 does not match the expected tables and columns.. Öffne noch einmal und belege, dass Markierung, Spalten und Kontrollzeile ihren vorherigen Werten entsprechen.

Baue jede geordnete Spaltenliste mit einer kurzen ausdrücklichen Schleife über PRAGMA table_info(members). Das hält den Nachweis lesbar, ohne hier eine neue Python-Ausdrucksform einzuführen.

Beide Zweige gehören in denselben Test, weil sie eine falsche Reparatur verhindern, die jede Datenbank der Version 1 ablehnt. Erfolg belegt, dass die Migration noch funktioniert; Ablehnung belegt, dass die Markierung allein nicht genügt. Akzeptiere nicht irgendeine Ausnahme. Ein OperationalError durch einen zu frühen Versuch mit ALTER TABLE belegt, dass der Code das Schema ändern wollte, bevor er es validiert hat.

Klicke auf Run. Der feste Einstieg ruft pytest.main(["-q", "-p", "no:cacheprovider", "tests/test_catalog.py"]) auf und sollte Folgendes ausgeben:

Database tests passed: 7

Submit prüft in separaten neuen Durchläufen eine Entscheidung nur anhand der Markierung und einen abgeschwächten Vergleich geordneter Spalten. Deine Vorher-nachher-Nachweise sollten beide ablehnen und zugleich einen funktionierenden Migrationsweg erhalten.