[Koha-bugs] [Bug 35610] Missing FK on old_reserves.branchcode?

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35610

Victor Grousset/tuxayo <victor at tuxayo.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Signed Off                  |Failed QA
                 CC|                            |victor at tuxayo.net

--- Comment #10 from Victor Grousset/tuxayo <victor at tuxayo.net> ---
As expected, doing an upgrade when there is
1. a hold on a library with no data linked (for easy deletion) in sample data:
Liberty
2. cancel the hold
3. delete the library
4. apply the patch
5. run updatedatabase

fails with:

DEV atomic update
/kohadevbox/koha/installer/data/mysql/atomicupdate/bug_35610.pl  [01:44:28]:
Bug 35610 - Add FK on old_reserves.branchcode
ERROR - {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: Cannot add or
update a child row: a foreign key constraint fails
(`koha_kohadev`.`#sql-alter-1-2f`, CONSTRAINT `old_reserves_ibfk_branchcode`
FOREIGN KEY (`branchcode`) REFERENCES `branches` (`branchcode`) ON DELETE SET
NULL ON UPDATE CASCADE) at /kohadevbox/koha/C4/Installer.pm line 741

That's a rough to have such an upgrade requiring manual DB fixes. And it's not
a weird workflow that can be considered messing with the DB.

There doesn't seem to be a mention about how to handle that in bug 25260.

How about before adding the FK having an UPDATE that NULLs the
old_reserves.branchcode that don't match an existing branch?
Or another approach?

---

(In reply to Katrin Fischer from comment #6)
> I was thinking maybe a better moment to fix might be when
> merging, because we could advertise that change a bit more.

What would be needed to advertise in advance? Like if they are using
old_reserves for stats they should stop, use action logs/statistics and backup
old_reserve before the future upgrade for past data?

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.