SearchApiSolrBackend is setting incorrect prefix to Search API reverse entity references

+++ b/src/Plugin/search_api/backend/SearchApiSolrBackend.php
@@ -1443,7 +1443,13 @@ class SearchApiSolrBackend extends BackendPluginBase implements SolrBackendInter
+                    $checkForReverseReference = 'search_api_reverse_entity_references';
+                    if (substr($field->getPropertyPath(), 0, strlen($checkForReverseReference)) === $checkForReverseReference) {

I consider this line to be easier ;-)

if (0 === strpos($field->getPropertyPath(), 'search_api_reverse_entity_reference')) {

Beside this, I think the check should happen on top of the getPropertyPathCardinality() function itself.

A test would be great, but I don't know if you can do it?
Maybe there's an existing test in Search API we should simply run on Solr?

Unfortunately there's no integration test in Search API that runs on a real backend.

Applied patch on project after encountering issue.
Issue was appearing when I was setting up Reverse entity references processor and indexing after adding field.

After applying, I managed to index and get correct result.
It worked for me.

Useful work-around.
However, I think the proper fix would be to also check for $property->isList() in \Drupal\search_api_solr\Plugin\search_api\backend\SearchApiSolrBackend::getPropertyPathCardinality.
However, this will not fix the problem until #3053603: Entity-typed processor properties don’t support isList() gets committed and becomes available, so for now this workaround definitely makes sense in any case.

Setting back to “Needs review”, but can of course also create a new issue for this.

@drunken monkey: Should the committed patch be reverted?
Does the call for isList() lead to "undefined function" with the current release of Search API?

@drunken monkey: Should the committed patch be reverted?

Once you can depend on the Search API commit being there, yes. (Not sure how you’d determine that – I don’t think a versioned dependency makes sense for just this? Probably just wait a bit, I’d say.)

Does the call for isList() lead to "undefined function" with the current release of Search API?

No, that’s defined right in the Typed Data API, so will always be there. The Search API patch just made it return the correct value for entity-valued processor fields.

Still experiencing this bug with the latest (Search API 8.x-1.14 & Search API Solr 8.x-3.6 ) versions.

Should I open new issue for this ?

I'm also getting this error with (Search API 8.x-1.16 & Search API Solr 8.x-3.9).

I get it with Search API 8.x-1.16 & Search API Solr 4.0.1

I also have this problem, Search API Solr 4.0.0.

Most recent patch doesn't fix, because the field's property_path doesn't match to the property array passed to $this->getPropertyPathCardinality(...), so it drops out of the function with default value 1.

 protected function getPropertyPathCardinality($property_path, array $properties, $cardinality = 1) {
    [$key, $nested_path] = SearchApiUtility::splitPropertyPath($property_path, FALSE);
    if (isset($properties[$key])) { 
      // nope, $key is search_api_reverse_reference... 
      // but $properties contains referencing datasource's properties only
      $property = $properties[$key];

Patch reroll from #5 for version 4.

#21 patch worked for me. TNX

I think there should be a better way to override this instead of hard-coding for Reverse Entity References. I have a processor that's doing something similar and needs a way of forcing the cardinality to unlimited as well.

See #3153385 for a possible solution.

Posting patches on a closed issue is a bad idea.

This should be fixed by #3153385: Improve field cardinality detection