Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.In the methods SearchApiSolrService::getFieldNames and SearchApiSolrService::searchMultiple, the field search_api_id is mapped to a non-existent doc element, ss_search_api_id, which results in an invalid item id in result sets:
// This array maps "local property name" => "solr doc property name".
$ret = array(
'search_api_id' => 'ss_search_api_id',
'search_api_relevance' => 'score',
'search_api_item_id' => 'item_id',
);
// Get field information
$solr_fields = array(
'search_api_id' => 'ss_search_api_id',
'search_api_relevance' => 'score',
'search_api_multi_index' => 'index_id',
);
Changing these fields to map to id instead maps to the correct Solr doc element. Patch to follow.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 2045355-3--correct_item_id_mapping.patch | 2.09 KB | drunken monkey |
| #1 | search_api_solr-search-api-id-fix-2045355-01.patch | 1.39 KB | arpieb |
Comments
Comment #1
arpieb CreditAttribution: arpieb commented... and here's the patch against 7.x-1.x, commit id 8d86923.
Comment #2
arpieb CreditAttribution: arpieb commentedComment #3
drunken monkeyThanks for reporting!
We previously had a
<copyField source="item_id" dest="ss_search_api_id" />directive inschema.xml(now gone because of the common configs), that's where this comes from. Although I'm not actually sure what the advantage was, compared to just using theitem_idfield directly … It seems it's becauseitem_idwasn't optimized for sorting – which of course makes no difference as long as the item IDs are numeric, which they usually are. And in this case, sorting on them using a string type leads to useless results anyways.So, on the whole I'd say this functionality is pretty useless anyways, but for the sake of completeness we should of course still fix the code. Changing the field mapping to
idisn't right, though – as said, it should refer to theitem_id. So I guess we can just change this and dropsearch_api_item_idcompletely.See the attached patch.
Comment #4
arpieb CreditAttribution: arpieb commentedIt's my understanding that item_id is equivalent to nid in this module, which is only unique for a specific site. If multiple sites are being indexed on a single Solr index, then item_id does not uniquely identify a search result item - but id does.
A use case - I'm working on a module that allows you to curate lists of items from across multiple sites using search to populate an auto complete. Without the globally-unique id element being made available, there is no way that field is ever going to work. There could be other cases as well, that is the one I'm currently running into though.
Beyond that - it's a required, defined element being returned by Solr that really should be included in the available fields for a search result item.
Comment #5
drunken monkeyWell, not quite. The
idis only unique as long as sites don't use the same index machine names. But of course, you'd have to follow that anyways for things to work.I don't really understand your use case, but multi-site functionality is definitely something we should support better than currently. If it'd help you this much, I guess we can just introduce a new
search_api_solr_idkey (or something similar) to the results.However, note that there's already
$return['search_api_solr_response']set on the return value of the search query for queries on the Solr server. From that, you could already get the Solr-specific IDs pretty easily, as well as any other fields you need.Comment #6
drunken monkeyCommitted.
Please re-open with more information if you need anything else for your use case (see my previous comment) – or, better still, open a new issue to keep things in order.