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


API changes


search_api-use-id-value-instead-array-key.patch2.79 KBdas-peter
PASSED: [[SimpleTest]]: [MySQL] 287 pass(es).
[ View ]


drunken monkey’s picture

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

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:

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