Hello people,
We hit a problem in search_api_solr with an error: "can not use FieldCache on multivalued field" when using the boost recent dates processor.
See issue: https://www.drupal.org/project/search_api_solr/issues/3326515
This problem became apparent between versions 4.2.8 and 4.2.9 of search_api_solr.
search_api_solr attempts to identify if a field is single or multi valued to apply the appropriate prefix to the field name.
At one point it calls $field->getDataDefinition()->isList()
See:
https://git.drupalcode.org/project/search_api_solr/-/blob/4.2.9/src/Plug...
For aggregated fields, this always returns true because of this line:
https://git.drupalcode.org/project/search_api/-/blob/8.x-1.28/src/Plugin...
The comment reads:
// Most aggregation types are single-valued, but "Union" isn't, and we
// can't know which will be picked, so err on the side of caution here.
Is it possible to accurately determine the cardinality of the field to update the is_list property?
Trying to work out if this can be fixed in search_api or needs further work arounds in search_api_solr.
Many thanks!
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 3340305-4--aggregated_field_correct_is_list.patch | 8.97 KB | drunken monkey |
Comments
Comment #2
cbrody commentedThanks @finn-lewis, seems to me that search_api is the logical place to fix this.
Comment #3
mkalkbrennerComment #4
drunken monkeyThanks for reporting this issue!
I guess it really is high time to think of a solution for this. How about something like the attached patch? I think, since there is a base class, the changes should be allowed under our BC policy, and this seems to resolve the problem.
Please test/review!
Comment #5
drunken monkeyWould be great to get feedback on my patch before I commit it, to make sure it actually fixes the problem.
Comment #6
finn lewisThanks drunken monkey!
I've tested this in the installation that was giving us the original problem reported on https://www.drupal.org/project/search_api_solr/issues/3326515
It does not fix the original problem but I can see that Saerch API is no longer declaring the aggregated field as a list, which is nice!
But now in search_api_solr the logic continues on from https://git.drupalcode.org/project/search_api_solr/-/blob/4.2.9/src/Plug...
to https://git.drupalcode.org/project/search_api_solr/-/blob/4.2.9/src/Plug...
where this line still sets the prefix to dm_
So I need to understand why the getPropertyPathCardinality is not returning 1 for the aggregated field.
So I think the patch looks good but perhaps reveals another part of the problem back in search_api_solr.
I'll follow up with that over on https://www.drupal.org/project/search_api_solr/issues/3326515
Comment #7
gertlor commentedI've made a patch to fix the problem reported by #6, see https://www.drupal.org/project/search_api_solr/issues/3326515#comment-14...
Comment #8
finn lewisThanks @Gertlor !
I've tested this patch with the patch on https://www.drupal.org/project/search_api_solr/issues/3326515#comment-14... and it does resolve our problem.
Is that enough for you to commit and perhaps get a new release @drunken monkey?
Comment #9
finn lewisComment #10
mkalkbrennerI agree with #4. Once it is committed, we can proceed in search_api_solr.
Comment #12
drunken monkeyGood to hear, thanks for your feedback!
Committed. Thanks again, everyone!
I also posted a change notice for this.