Problem/Motivation
Calling \Drupal::service('locale.storage')->deleteStrings() never seems to work.
It fails with this error:
Drupal\Core\Database\InvalidQueryException Calling Drupal\Core\Database\Query\Condition::condition() without an array compatible operator is not supported. See https://www.drupal.org/node/3350985.
The problem is that dbDelete() loops on provided values and adds a condition to the query for each value but it uses a = condition so it only works with scalar values.
deleteStrings() calls dbDelete() with an array of LIDs as value, so it tries to add a query condition with the = operator and an array as value, which does not work.
(This method does not seem to be used by core itself.)
Steps to reproduce
\Drupal::service('locale.storage')->deleteStrings(['lid' => 1]);
Proposed resolution
StringDatabaseStorage::dbDelete() should use an IN condition.
This way StringDatabaseStorage::deleteStrings() can call it with multiple LIDs and they will all be deleted.
In order to keep compatibility with other methods that call dbDelete(), we can check if the value is scalar and create an array that contains only this scalar value that we use in the IN condition.
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3497647
Show commands
Start 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:
Comments
Comment #2
prudloff commentedComment #3
quietone commentedChanges are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies.
Comment #5
prudloff commentedComment #6
smustgrave commentedCan the issue summary be flushed out some please
Proposed solution is a little vague, don't need code examples but how is this being solved.
Also recommend leaving all summary headers, if they are blank or NA.
Comment #7
prudloff commentedTried to improve issue summary.
Comment #8
smustgrave commentedMuch better!
Comment #9
quietone commentedComment #10
prudloff commentedI moved the test to a kernel test.
Comment #11
smustgrave commentedFeedback of switching to a kernel test appears to be addressed
Comment #12
xjmI queued the test-only changes job (which someone should have done and documented before this was RTBC).
Comment #13
xjmThe test-only job failed as expected (with the error as reported in the original issue):
https://git.drupalcode.org/issue/drupal-3497647/-/jobs/5279091
Comment #14
xjmI reviewed the relevant APIs, and I agree that this is a good fix. Saving credits.
Comment #15
xjmSorry, just caught a couple assertion messages creeping back in. @prudloff, are you okay with the inline comments I proposed instead, in place of your assertion messages? If you accept the suggestions, the issue can be moved straight back to RTBC (no need for an extra review cycle for it).
Comment #16
prudloff commentedSorry I didn't know that assertion messages should not be used. (Maybe a phpcs rule delicould catch that?)
I am OK with your changes.
Comment #20
xjm@prudloff, it's one of those "cultural knowledge" things where it's been enforced as a best practice in the core queue and been the subject of repeated massive codebase cleanups, but the policy draft to formalize it has stalled out for years. :) Tried to get the latest version of it moving again today in #3131946: [policy] Remove PHPUnit assertion messages when possible, and standardize remaining messages . Unfortunately there are a subset of cases where messages are needed (the policy draft in the linked issue outlines them), so enforcing it with a rule isn't as simple as some.
In any case, thanks for the bug fix! I went back and forth on the priority, but I think this is actually major, given that the method as it stands is basically straight-up broken.
Committed to 11.x, 11.2.x, and 10.5.x as a patch-safe major bug fix. Thanks!
Comment #22
xjm