Bewijs dat een import halverwege de batch wordt teruggedraaid

Een rollback van een import is alleen betekenisvol wanneer de fout optreedt nadat nieuw werk is begonnen. Zet eerst een echt nieuwe CSV-rij neer, daarna een afwijkende rij en bewijs vervolgens dat de eerdere rij niet is blijven staan.

Ga verder in tests/test_catalog.py. Maak test_failed_import_rolls_back_every_new_item(tmp_path) af met import-rollback.db en late-conflict.csv, beide onder tmp_path. Zet in de database één opgeslagen voorwerp klaar, bijvoorbeeld met inventariscode KEPT-7 en de oorspronkelijke naam, en commit het. Sluit die verbinding voordat je de importfunctie aanroept die zelf het pad beheert.

Schrijf een geldige CSV met vijf kolommen. De eerste rij moet een nieuw ID en een nieuwe code hebben. De tweede rij moet KEPT-7 hergebruiken, maar één veld veranderen dat de CSV beheert, zoals de naam. De lezer en validator moeten het volledige bestand accepteren; de afwijking wordt pas zichtbaar wanneer de voorbereide batch wordt vergeleken met de opgeslagen toestand.

Roep precies catalog_import.import_items_csv(database_path, csv_path) aan binnen pytest.raises(ValueError). Vergelijk de exacte melding CSV item KEPT-7 disagrees with the stored item.. Open de database daarna opnieuw en selecteer alle vijf de voorwerpvelden op volgorde van ID. Het volledige resultaat mag alleen de oorspronkelijke opgeslagen rij bevatten. Die assertion bewijst beide kanten van de transactiegarantie: de vroege nieuwe rij ontbreekt en de oude rij is niet vervangen of bewerkt.

Als de conflicterende rij als eerste komt, is er vóór de fout nog niets geschreven. Zelfs een defecte commit per rij kan dan slagen. Alleen het aantal rijen controleren is ook te zwak, omdat één verwijderde rij en één ten onrechte achtergebleven rij nog steeds hetzelfde aantal kunnen opleveren. Vergelijk de waarden die ertoe doen.

Druk op Run. Het vaste startpunt roept pytest.main(["-q", "-p", "no:cacheprovider", "tests/test_catalog.py"]) aan en moet dit melden:

Database tests passed: 6

Submit controleert twee verkeerde commitmomenten afzonderlijk: committen na elke insert en committen voordat de volgende rij wordt beoordeeld. Elke uitvoering begint in een nieuw project en vindt dezelfde zes tests. Jouw opzet met een later conflict moet beide fouten blootleggen zonder afhankelijk te zijn van ID’s of tekst uit de startcatalogus.