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!

Comments

Finn Lewis created an issue. See original summary.

cbrody’s picture

Thanks @finn-lewis, seems to me that search_api is the logical place to fix this.

mkalkbrenner’s picture

drunken monkey’s picture

Status: Active » Needs review
StatusFileSize
new8.97 KB

Thanks 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!

drunken monkey’s picture

Would be great to get feedback on my patch before I commit it, to make sure it actually fixes the problem.

finn lewis’s picture

Thanks 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_

$pref .= $this->getPropertyPathCardinality($field->getPropertyPath(), $index_properties) != 1 ? 'm' : 's';

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

gertlor’s picture

I've made a patch to fix the problem reported by #6, see https://www.drupal.org/project/search_api_solr/issues/3326515#comment-14...

finn lewis’s picture

Thanks @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?

finn lewis’s picture

Status: Needs review » Reviewed & tested by the community
mkalkbrenner’s picture

I agree with #4. Once it is committed, we can proceed in search_api_solr.

  • drunken monkey committed cea94cd2 on 8.x-1.x
    Issue #3340305 by drunken monkey: Fixed all aggregated fields being...
drunken monkey’s picture

Status: Reviewed & tested by the community » Fixed

Good to hear, thanks for your feedback!
Committed. Thanks again, everyone!

I also posted a change notice for this.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.