--- Comment #36 from Benjamin Rokseth <benjamin.roks...@deichman.no> ---
(In reply to Benjamin Rokseth from comment #32)
> (In reply to Ere Maijala from comment #31)
> > I'm working on it now.
> > Looks like there may be a typo in the atomic update. I got the following
> > error:
> > updatedatabase.pl: DBD::mysql::db do failed: Can't DROP FOREIGN KEY
> > `deletedbiblio_metadata_fk_1`; check that it exists [for Statement "ALTER
> > TABLE deletedbiblio_metadata DROP FOREIGN KEY deletedbiblio_metadata_fk_1"]
> > at (eval 1389) line 8.
> > Looking at the old kohastructure.sql I believe it should have tried to drop
> > 'deletedrecord_metadata_fk_1'.
> hmm, sad to say, but no, it's not a typo but db design issues.
> this commit seems to have added to the confusion:
> 739e2e0c5dc26502e195e2cc4c687ababdcaf381 (Bug 17196)
> and following Bug 18284 you can see that most agree on deleted* tables being
> a bad idea in the first place.
> Problem is, kohastructure.sql and updatedatabase.pl is not in sync and
> libraries having migrated from 16.05 and before would need to delete this
> foreign key. And this patch is most important for them anyways.
> I suppose we could add a delete foreign key for both and ignore errors
> rather than die in the final version
fail to remember, but probably I put it there because otherwise it complained,
perhaps due to the "rename table". the idea was that any leftovers from
conflicts should be moved to temporary tables (prepended with _) so that one
could check and delete them at convenience
I will remove the dies in the atomicupdate and see if it works for us
You are receiving this mail because:
You are watching all bug changes.
Koha-bugs mailing list
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/