Initially I have indexed a few products using search API. But later, I removed the indexed products and recreate new products. Now when I try to re-setup search API, I was trying to execute pending tasks, but I could not get past an error page.
The error page reads
An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /batch?id=51&op=do_nojs&op=do
StatusText: 500 Service unavailable (with message)
ResponseText: The website encountered an unexpected error. Please try again later.
The error message reads
"Drupal\search_api\SearchApiException: SQLSTATE[42000]: Syntax error or access violation: 1171 All parts of a PRIMARY KEY must be NOT NULL; if you need NULL in a key, use UNIQUE instead: ALTER TABLE {search_api_db_default_index_sku} CHANGE `value` `value` BIGINT DEFAULT NULL COMMENT 'The field\'s value for this item'; Array ( ) in Drupal\search_api_db\Plugin\search_api\backend\Database->fieldsUpdated() (line 1044 of /var/www/drupal/modules/search_api/modules/search_api_db/src/Plugin/search_api/backend/Database.php)."
Please help me. I have tried to google on this issue and browse through the issue list over here but could not get any relevant answer.
Comments
Comment #2
shadeworm commentedComment #3
drunken monkeyThanks a lot for reporting this problem!
Looking at this, the mistake is obvious: when altering existing table definitions, we neglect to set "not null" to
TRUEfor the value columns, which we normally do. This didn't cause any visible problems (probably just a bit of lost performance) until #2884451: search_api_db tables should be created with a primary key landed and added primary keys to those tables. Now, this of course blows up, as you see.The attached patch should fix this, please test!
Also, we should add a test to make sure this keeps working.
Comment #4
borisson_I'm not sure if we need to test this actually, it's a database definition. However, the code looks great!
Comment #5
drunken monkeyWell, it did cause an error, so I do think a regression test is in order. Normally you're the one who's all "We need tests!" all the time – stop making me be the responsible one!
However, I'm failing anyways to reproduce the problem in the first place. For me, all three DBMSs (even Postgres!) seem to auto-correct the
ALTER TABLEstatement to make all necessary columnsNOT NULL.@ shadeworm: What database and version are you using? Any special config options maybe? In case you're familiar with SQL, it would be great if you could provide basic SQL steps to reproduce. I did the following, but didn't encounter any errors:
Comment #6
.jch commentedApache/2.4.25 (x64) PHP/7.2.2 ~ Core 8.5.0-rc1 ~ MySQL 5.7.20-log
search_api (dev-1.x build 21f5a31) appears to have resolved the null primary key issue for MySQL 5.7 with the above config.
Will continue testing.
Outstanding work!
Comment #7
borisson_I like this, and we had a manual verification of the patch. Let's get this in.
Comment #9
drunken monkeyGood to hear, thanks for reviewing!
Committed.
Thanks again, everyone!