On some sites (I cannot make out any relevant difference between those that work and those that don't), an update to 8.x-1.21 is not successful because of the following error:
$ drush -l mydomain.at updb
------------ ----------- --------------- --------------------------------
Module Update ID Type Description
------------ ----------- --------------- --------------------------------
search_api 8107 hook_update_n Add a unique index to the task
entity type's storage.
search_api 8108 hook_update_n Add configuration for boost
factors.
search_api 8109 hook_update_n Enable index entity references
option by default on existing
indexes.
------------ ----------- --------------- --------------------------------
Do you wish to run the specified pending updates? (yes/no) [yes]:
>
> [notice] Update started: search_api_update_8107
> [error] Call to a member function setHandlerClass() on null
> [error] Update failed: search_api_update_8107
[error] Update aborted by: search_api_update_8107
[error] Finished performing updates.No amount of --verbose or --debug or looking at log files gives any more clues as to what exactly happens/goes wrong.
This only happens on sites where search_api and search_api_db are enabled but not yet configured (this is work in progress) - but this may be unrelevant. There are sites on the same multisite installation that have unconfigured search_api and search_api_db as well that update their DB flawlessly. I'm really at a loss as to what can be the difference.
Just drush updb after an update from 8.x-1.20 to 8.x-1.21.
I changed to
innodb_large_prefix=on
innodb_default_row_format=dynamicon MariaDB 10.1.48, restarted MariaDB, and did an
ALTER TABLE `<tablename>` ROW_FORMAT=Dynamic;
to all the tables before to fix https://www.drupal.org/project/search_api/issues/3247781. I don't know if this is relevant. As I already said, all other sites except 3 got the same treatment and it worked out flawlessly. Therefore I'm not adding the issue as related yet.
An uninstall/enable cycle fixes it for me.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 3248262-6--update_8107_fail_entity_type_null.patch | 2.97 KB | drunken monkey |
| #4 | search_api-update-8107-failure-3248262-4.patch | 670 bytes | Robert_T |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
compare
Comments
Comment #2
tgoeg commentedAlright, so this seems unrelated to the row format update.
On another server running MySQL 5.7.36, no row format update was needed.
Only 1 site showed the problem.
Something strange happens when trying to uninstalling/installing search_api:
The temp dir is at /tmp and is of course writable, working flawlessly on all sites.
Running the same command a second time works:
So reinstallation worked here as well, but I am completely clueless as to what this error might be and whether it might cause the initial error.
Comment #4
Robert_T commentedI had the same issue on a website after an update from 8.x-1.20 to 8.x-1.21. Table search_api_task is empty, which seems to indicate that there are no search_api_task objects, so the update fails.
This patch did the trick for me.
Comment #5
mikebarkas commentedI updated from 1.20 to 1.21 and got the same
drush updberror.I had an empty
search_api_tasktable as well and applied @Robert_T patch.Patch #4 worked for me, allowed me to run
drush updb.Comment #6
drunken monkeyThanks a lot for reporting this problem!
I don’t really see what the contents of the
search_api_tasktable would have to do with this, but yes, if$entity_typecan in some cases beNULL, I guess we should just check for that.However, as also discussed in #3260230-6: Error on search_api_update_8110, this update function has actually become superfluous in the meantime – there is already another update function, 8110, which just undoes it. So, we might as well remove the whole function code – but should then, of course, similarly guard the 8110 update function against this problem. (Also, I guess, no need to do anything if no handler was actually set in 8107?)
The attached patch would implement this, please test/review!
Comment #7
drunken monkeyComment #8
samlerner commentedI ran into this problem on Acquia Cloud, and neither this patch nor ones on https://www.drupal.org/project/search_api/issues/3260230 did the trick.
However, I DID manage to fix things by disabling search_api, running database updates, and then re-enabling it and all its dependent modules.
Given the error looks like this bug in MySQL tables the only other fix would be a full database restore, which would rebuild the tables, and allow the database updates to work. This is why it was working for me in lower Acquia environments, but failed on production.
Comment #10
drunken monkeyWell, once the database update has run, this patch will of course not help with the problem. Still, it shouldn’t do any harm (I sincerely hope) and help prevent problems for people who are late in upgrading. (Seems like about half of D8 users is still on version 1.20 or below, meaning they still need to make this update.)
I don’t think there is much more to do for this ticket, anything else should be done either in #3260230: Error on search_api_update_8110 or in a new ticket.