https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28528 Roman Dolny <roman.dolny@jezuici.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Trivial patch Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28528 Roman Dolny <roman.dolny@jezuici.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |roman.dolny@jezuici.pl Assignee|koha-bugs@lists.koha-commun |roman.dolny@jezuici.pl |ity.org | -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28528 Janusz Kaczmarek <januszop@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #176844|0 |1 is obsolete| | --- Comment #2 from Janusz Kaczmarek <januszop@gmail.com> --- Created attachment 180606 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=180606&action=edit 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> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28528 Janusz Kaczmarek <januszop@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |major -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28528 --- Comment #5 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (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. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28528 Janusz Kaczmarek <januszop@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Signed Off --- Comment #7 from Janusz Kaczmarek <januszop@gmail.com> --- (In reply to Marcel de Rooy from comment #6)

Moving to In Discussion. If you pass -fk and we are still going to delete, this may be confusing?

If someone calls the script with -fk, we assume that they are aware of the consequences and know what they are doing. As far as I remember, -fk appeared in this script when we introduced foreign keys on a larger scale, and execution with just -d became impossible in some cases (e.g., existing issues). We have two problems here, both solved with this patch: 1. Calling with -d, without -fk (when there are no dependencies blocking the deletion of records) causes the biblio_metadata table to be empty, but AUTO_INCREMENT in biblio_metadata remains set to the old value and increments differently than biblionumber (which is not a big technical problem, but will raise unnecessary questions or doubts). 2. Calling with -d and -fk causes biblio_metadata to retain rows that are not related to the biblio and biblioitems tables, which probably makes no sense. This is also not a technical problem, but it is a problem nonetheless, because this data takes up space completely unnecessarily and creates inconsistency in the data. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28528 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #180606|0 |1 is obsolete| | --- Comment #8 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 193504 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=193504&action=edit 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> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28528 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |m.de.rooy@rijksmuseum.nl |y.org | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28528 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |26.05.00 released in| | Status|Passed QA |Pushed to main -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28528 Jacob O'Mara <jacob.omara@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)|26.05.00 |26.05.00,25.11.04 released in| | Status|Pushed to main |Pushed to stable -- You are receiving this mail because: You are watching all bug changes.