Problem/Motivation

I'm currently working on a new module (Search API Grouping) that allows you to split indexing item on behalf of a multivalue field. At the same time the module provides result grouping based on this: #1721262: Field collapsing
This featureset becomes handy if you've to do some complex searches which fail using a multivalue field (e.g. Date-Repeats).
The problem is, that I've to provide unique ids for the items to index. Thus I add the delta of the multivalue field to the original id in preprocessIndexItems().
In postprocessSearchResults() I restore the original id of the results.
Unfortunately, in SearchApiViewsQuery::addResults() the array key (which I can't change) is used instead the id value of the result item to fetch the related entities.

Proposed resolution

Change the code to deal with the id value of the result items instead the array key - which is more like a search index id than result id. The attached exactly does this.

If there's a smarter way to provide this feature e.g. having control over the created search index id without affecting the result id I'll happily change the approach - currently a lot of pre/post processing is necessary...

Remaining tasks

  • Clarify if other locations need to be adjusted to handle this use case (Search Pages?)
  • Reviews needed

User interface changes

None

API changes

None

CommentFileSizeAuthor
search_api-use-id-value-instead-array-key.patch2.79 KBdas-peter
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
CreditAttribution: drunken monkey commented

Excerpt of the documentation for SearchApiQueryInterface::execute():

  - results: An array of results, ordered as specified. The array keys are
    the items' IDs, values are arrays containing the following keys:
    - id: The item's ID.

In this context it probably is a shortcoming of the API, but the contract clearly states that array key and id value have to be the same for the returned results.

I think the cleaner way of going about this for you would be to implement a datasource controller. That way, you can just ignore part of the ID for loading results, and everything should work as expected.
OK, except for the problem encountered in #1760706: Add a flexible way for determining whether an index contains entities (which seems to be about the same thing that you're trying to do).

Relying on undocumented internal behaviour and violating interface contracts doesn't seem like the safest/cleanest way to do this, in any case.

das-peter’s picture

das-peter CreditAttribution: das-peter commented
Status: Needs review » Postponed

I've adapted the approach of Jeff Graham (jgraham) #1760706: Add a flexible way for determining whether an index contains entities
His sandbox contains now a 7.x-2.x branch: http://drupal.org/sandbox/jgraham/1777454

However, this could be an API change for the next major version of Search API, right?

legolasbo’s picture

legolasbo
he/him
Primary language Dutch
Location Middelburg
CreditAttribution: legolasbo at Ordina Digital Services commented
Status: Postponed » Closed (outdated)

This issue has not seen activity in over 2,5 years. I am therefore closing this issue to clean up the issue queue. Feel free to re-open and update this issue if you feel this issue is still relevant and of importance.