Closed
Bug 1375835
Opened 7 years ago
Closed 7 years ago
AWFY: update SQL requests after mysqld restart
Categories
(Testing Graveyard :: AWFY, enhancement)
Testing Graveyard
AWFY
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: bbouvier, Assigned: bbouvier)
Details
We did a restart of all the services on the AWFY's website because of bug 1375003. That included a mysqld restart, and I suspect some version changed, or some default setting changed. As a matter of fact, SQL requests made by the web site seem to raise errors, because SQL requests aren't valid anymore. In particular, for any insertion of new items into the database, default values were implicitly used each time we omitted to use precise values for some fields. After this restart, these requests are failing with a mysql error saying that explicit values should be used or there should be a default value in the database. Not sure what's best: to change the table's structure or to update all the requests to include default values?
Assignee | ||
Updated•7 years ago
|
Component: JavaScript Engine → General
Product: Core → Testing
Version: unspecified → Trunk
Comment 1•7 years ago
|
||
probably safer to change table structure, in addition to making the code have default values for all requests :)
Comment 2•7 years ago
|
||
+1
Assignee | ||
Comment 3•7 years ago
|
||
Thanks, indeed it makes even more sense. A first commit to have better SQL error reporting: https://github.com/mozilla/arewefastyet/commit/8d4d05c0ddba4168b654ac9141475a3a48e9225c Before, callers of mysql_query would sometimes use the idiom `mysql_query($query) or die(mysql_error())`, which is one way to signal error. But a lot of callers would miss this, in particular for `INSERT` queries, silently ignoring them and meaning they wouldn't appear on the logs. The above idiom was already factored out into a `awfy_query()` function, which is consistently used in this commit. I'll put this in production right now.
Assignee | ||
Updated•7 years ago
|
Assignee: nobody → bbouvier
Status: NEW → ASSIGNED
Assignee | ||
Comment 4•7 years ago
|
||
The fixes are all in the https://github.com/mozilla/arewefastyet/commits/fix-sql branch, which I've put in production to see if it fixes the errors. I'll check error logs and the database for an hour, and if it fixes the issues, I'll merge into the master branch.
Assignee | ||
Comment 5•7 years ago
|
||
This fixed it. New runs are appearing again on the website. I've merged the fix-sql branch into the master branch: https://github.com/mozilla/arewefastyet/compare/cd1ec84c336ea520983b67dae8a5bf88f42f48cd...caf8e6c6036407f7de0c073e40d7467f22642974 The better logging uncovered another SQL error that was swallowed before; at least the refactoring was useful for this.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Updated•7 years ago
|
Component: General → AWFY
Updated•4 years ago
|
Product: Testing → Testing Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•