Summary: | bulkmarcimport delete option doesn't delete biblio_metadata | ||
---|---|---|---|
Product: | Koha | Reporter: | Katrin Fischer <katrin.fischer> |
Component: | Command-line Utilities | Assignee: | Roman Dolny <roman.dolny> |
Status: | In Discussion --- | QA Contact: | Testopia <testopia> |
Severity: | major | ||
Priority: | P5 - low | CC: | januszop, m.de.rooy, robin, roman.dolny |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | Trivial patch | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Attachments: |
Bug 28528: bulkmarcimport delete option doesn't delete biblio_metadata
Bug 28528: bulkmarcimport delete option doesn't delete biblio_metadata |
Description
Katrin Fischer
2021-06-08 11:08:54 UTC
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? |