Summary: | Use of FOREIGN_KEY_CHECKS = 0 | ||
---|---|---|---|
Product: | Koha | Reporter: | Chris Cormack <chris> |
Component: | Installation and upgrade (web-based installer) | Assignee: | Bugs List <koha-bugs> |
Status: | CLOSED WONTFIX | QA Contact: | Bugs List <koha-bugs> |
Severity: | major | ||
Priority: | P2 | CC: | gmcharlt, jonathan.druart, kyle, mjr, paul.poulain, tomascohen, ztajoli |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: |
Description
Chris Cormack
2010-05-21 00:29:39 UTC
Restoring where "Previous assignee was mjr@ttllp.co.uk" Yep, having it in the kohastructure.sql makes sense, but not in updatedatabase.pl It is in 3 places in updatedatabase.pl This bug hasn't been touched in almost 3 years. I am resetting the asignee to default - MJ, please undo if you plan on working on this. Please take it with my blessing. It looks like it either dates from my time as default assignee for the installer or from an overbroad post-migration reset. This is currently the oldest open bug report, filed in May 2010. A quick git grep for "SET FOREIGN_KEY_CHECKS" reveals a lot of occurrences (see below) - Do we intend on fixing those? Or should this be a WONTFIX? - What is the goal here? Should we move some of the ideas from here to new more specific bug reports? installer/data/mysql/de-DE/optional/sample_creator_data.sql:/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */; installer/data/mysql/en/optional/sample_creator_data.sql:/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */; installer/data/mysql/es-ES/optional/sample_creator_data.sql:/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */; installer/data/mysql/it-IT/marcflavour/unimarc/necessari/authority_framework.sql:SET FOREIGN_KEY_CHECKS=0; installer/data/mysql/it-IT/marcflavour/unimarc/necessari/authority_framework.sql:SET FOREIGN_KEY_CHECKS=1; installer/data/mysql/it-IT/marcflavour/unimarc/necessari/unimarc_framework.sql:SET FOREIGN_KEY_CHECKS=0; installer/data/mysql/it-IT/marcflavour/unimarc/necessari/unimarc_framework.sql:SET FOREIGN_KEY_CHECKS=1; installer/data/mysql/it-IT/necessari/auth_val.sql:SET FOREIGN_KEY_CHECKS=0; installer/data/mysql/it-IT/necessari/auth_val.sql:SET FOREIGN_KEY_CHECKS=1; installer/data/mysql/it-IT/necessari/class_sources.sql:SET FOREIGN_KEY_CHECKS=0; installer/data/mysql/it-IT/necessari/class_sources.sql:SET FOREIGN_KEY_CHECKS=1; installer/data/mysql/it-IT/necessari/message_transport_types.sql:SET FOREIGN_KEY_CHECKS=0; installer/data/mysql/it-IT/necessari/message_transport_types.sql:SET FOREIGN_KEY_CHECKS=1; installer/data/mysql/it-IT/necessari/sample_creator_data.sql:/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */; installer/data/mysql/it-IT/necessari/sample_holidays.sql:SET FOREIGN_KEY_CHECKS=0; installer/data/mysql/it-IT/necessari/sample_holidays.sql:SET FOREIGN_KEY_CHECKS=1; installer/data/mysql/it-IT/necessari/sample_itemtypes.sql:SET FOREIGN_KEY_CHECKS=0; installer/data/mysql/it-IT/necessari/sample_itemtypes.sql:SET FOREIGN_KEY_CHECKS=1; installer/data/mysql/it-IT/necessari/sample_notices_message_attributes.sql:SET FOREIGN_KEY_CHECKS=0; installer/data/mysql/it-IT/necessari/sample_notices_message_attributes.sql:SET FOREIGN_KEY_CHECKS=1; installer/data/mysql/it-IT/necessari/sample_notices_message_transports.sql:SET FOREIGN_KEY_CHECKS=0; installer/data/mysql/it-IT/necessari/sample_notices_message_transports.sql:SET FOREIGN_KEY_CHECKS=1; installer/data/mysql/it-IT/necessari/stopwords.sql:SET FOREIGN_KEY_CHECKS=0; installer/data/mysql/it-IT/necessari/stopwords.sql:SET FOREIGN_KEY_CHECKS=1; installer/data/mysql/it-IT/necessari/userflags.sql:SET FOREIGN_KEY_CHECKS=0; installer/data/mysql/it-IT/necessari/userflags.sql:SET FOREIGN_KEY_CHECKS=1; installer/data/mysql/kohastructure.sql:/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */; installer/data/mysql/labels_upgrade.pl: SET FOREIGN_KEY_CHECKS = 0; installer/data/mysql/nb-NO/2-Valgfritt/sample_creator_data.sql:/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */; installer/data/mysql/patroncards_upgrade.pl: SET FOREIGN_KEY_CHECKS = 0; installer/data/mysql/updatedatabase.pl: $dbh->do('SET FOREIGN_KEY_CHECKS=0 '); installer/data/mysql/updatedatabase.pl: $dbh->do('SET FOREIGN_KEY_CHECKS=1 '); installer/data/mysql/updatedatabase.pl: $dbh->do('SET FOREIGN_KEY_CHECKS=0 '); installer/data/mysql/updatedatabase.pl: $dbh->do('SET FOREIGN_KEY_CHECKS=1 '); installer/data/mysql/updatedatabase.pl: $dbh->do("SET FOREIGN_KEY_CHECKS=0 "); installer/data/mysql/updatedatabase.pl: $dbh->do("SET FOREIGN_KEY_CHECKS=1 "); misc/maintenance/fix_mysql_constraints.pl: $dbh->do("SET FOREIGN_KEY_CHECKS=0"); misc/migration_tools/22_to_30/phrase_log.sql:/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */; misc/migration_tools/bulkmarcimport.pl: $dbh->do("SET FOREIGN_KEY_CHECKS = 0"); misc/migration_tools/bulkmarcimport.pl: $dbh->do("SET FOREIGN_KEY_CHECKS = 1"); I think we can wontfix it. There are some lines that are valid : the foreign_key_check=0 is necessary when you restore a dump : you don't want koha to check fk, because 1- sometimes you're temporary setting invalid data and 2- it slows the dump restore. Maybe there are some that are non necessary, but they're harmless. So wontfix is fair (and thanks for reviving those oldies !!!) Hi, many files with FOREIGN_KEY_CHECKS = 0 / FOREIGN_KEY_CHECKS = 1 are from it-IT. We insert in this way beacause we use then also to restore in working installations. And w e need to temporary setting invalid data. Ok on wont'fix I'm still not comfortable with wontfix because this could be avoided by correct ordering of the database files... it's lazy programming to turn key-checking off, isn't it? However, it's more dangerous in updates than the installer, because it's easier to test that the installer won't leave a broken/inconsistent database. If you want to wontfix this about the installer and then create bugs for the updates switching off key-checks, then that would be OK in my opinion. I would be quite uncomfortable about touching those old updatedatabase statementements. They all belong to the 'new acquisition module' that we introduced prior to 3.2 release and are rather complicated: $DBversion = '3.01.00.073' "Upgrade to $DBversion done (adding aqcontract table)\n"; $DBversion = '3.01.00.076'; "Upgrade to $DBversion done (adding basketgroups)\n"; $DBversion = '3.01.00.076'; "Upgrade to $DBversion done (Adding new aqbudgetperiods, aqbudgets and aqbudget_planning tables )\n"; I think it's not worth risking to break those. And they would be really hard to test, as we probably can't find a database with acq data that old easily. (In reply to Katrin Fischer from comment #9) > I think it's not worth risking to break those. And they would be really hard > to test, as we probably can't find a database with acq data that old easily. +1 |