When using bulkmarcimport with the -d switch should not only delete biblio, biblioitems and items, but also biblio_metadata. I haven't checked if a FK takes care of the data, but if it does, we should still also reset the AUTO_INCREMENT: https://git.koha-community.org/Koha-community/Koha/src/branch/master/misc/migration_tools/bulkmarcimport.pl#L172
Created attachment 176844 [details] [review] Bug 28528: bulkmarcimport delete option doesn't delete biblio_metadata When using bulkmarcimport with the -d switch should not only delete biblio, biblioitems and items, but also biblio_metadata. I haven't checked if a FK takes care of the data, but if it does, we should still also reset the AUTO_INCREMENT:... Test plan: ========== 1. Check (and notice) the number of records in the biblio (bCount) and biblio_metadata (bmCount) tables. Check the AUTO_INCREMENT value for these tables (bAI, bmAI). 2. Import bibliographic records with delete, turn off foreign key checks and non-existent filename: misc/migration_tools/bulkmarcimport.pl -b -d -fk -file=non-exist-file ==> "Could not open..." is OK, file doesn't exist. 3. Repeat p. 1 and compare with previously noticed: bCount => 0 (OK) bmCount => unchanged (NOT OK) bAI => 1 (OK) bmAI => unchanged (NOT OK) 4. Apply the patch. 5. Repeat p. 2-3: bCount => 0 (OK) bmCount => 0 (changed, OK) bAI => 1 (OK) bmAI => 1 (changed, OK) Sponsored-by: Ignatianum University in Cracow
Created attachment 180606 [details] [review] Bug 28528: bulkmarcimport delete option doesn't delete biblio_metadata When using bulkmarcimport with the -d switch should not only delete biblio, biblioitems and items, but also biblio_metadata. I haven't checked if a FK takes care of the data, but if it does, we should still also reset the AUTO_INCREMENT:... Test plan: ========== 1. Check (and notice) the number of records in the biblio (bCount) and biblio_metadata (bmCount) tables. Check the AUTO_INCREMENT value for these tables (bAI, bmAI). 2. Import bibliographic records with delete, turn off foreign key checks and non-existent filename: misc/migration_tools/bulkmarcimport.pl -b -d -fk -file=non-exist-file ==> "Could not open..." is OK, file doesn't exist. 3. Repeat p. 1 and compare with previously noticed: bCount => 0 (OK) bmCount => unchanged (NOT OK) bAI => 1 (OK) bmAI => unchanged (NOT OK) 4. Apply the patch. 5. Repeat p. 2-3: bCount => 0 (OK) bmCount => 0 (changed, OK) bAI => 1 (OK) bmAI => 1 (changed, OK) Sponsored-by: Ignatianum University in Cracow Signed-off-by: Janusz Kaczmarek <januszop@gmail.com>
NB, without this patch after performing bulkmarcimport.pl -d -fk old content of biblio_metadata remains in the table!
(In reply to Janusz Kaczmarek from comment #3) > NB, without this patch after performing bulkmarcimport.pl -d -fk old content > of biblio_metadata remains in the table! Yeah, but thats probably the idea behind passing -fk to block the foreign key's cascaded delete.
(In reply to Katrin Fischer from comment #0) > When using bulkmarcimport with the -d switch should not only delete biblio, > biblioitems and items, but also biblio_metadata. > > I haven't checked if a FK takes care of the data, but if it does, we should > still also reset the AUTO_INCREMENT: Yes, it has a FK with delete.
Moving to In Discussion. If you pass -fk and we are still going to delete, this may be confusing?