Views integration is out of sync with Search API

Try with other format options (e.g., table). You seem to have selected a row style that isn't compatible to the Search API.

I still can't reproduce this, but with #1231512: Use real Relationships instead of level magic in Views integration the whole Views integration will become invalid anyways. So if this is a bug, we can't really fix it now but will have to rewrite most of the Views integration, probably.
Sorry, that will probably take some time as development of this module currently isn't sponsored and I don't have much time at the moment.

For fixing your problem now, have you tried the latest dev version of the Search API?

Seeing that Search API switched over to using the Entity API Views integration more extensively we need to update this here as well. I am going to write a quick patch for this.

Great, thanks!

fubhy, How is your work on this patch going? If you are stalled, can you provide details on what others could do to help?

@ fubhy, I second that. How are things going with the patch and is there any areas I could assist?

Cheers,

David

I am getting the same issue as reported by another user. I get an error saying that the function _search_api_views_field_handler() is missing.
This kills the site. Oh, and make sure to clear the cache. I thought I had things working until I cleard the cache and got the WSoD.

Any updates on this issue?
Its the only thing holding my project back from production!
I would help if I could but this search stuff is over my head.
Thanks so much for all the hard work thus far - what is in place now is pretty amazing.

I created some patch which integrates Entity API.
It adds new service class, so you should recreate search server and use service class which provided by this module.

I applied the patch at #11, it did not apply cleanly to any of the current search_api_multi releases. So I had to had apply the patch for a few files. But once I did that I can confirm that this does indeed work! Thanks very much @TonyPa!

The patch at #11 somewhat worked for me. It applied correctly, and I got a new service class.

I've added my node index and my user index to the new service, but when I'm searching through both indexes using a newly created view, I will only get results from one entity at a time.

Example: Let's say I have a node with the title Foo, and a user named Foo Bar, I will only get the node results when searching for Foo.

fixed bug at #13
added cron hook

apply this patch to 7.x-1.x-dev release
there is no difference between dev and beta

last patch doesn't want to apply

I applied this to the latest dev release, and it didn't fix the error. It didn't apply at lines 163,7 -> 113,7.

Unpatched:

    $table['search_api_multi_index']['title'] = t('Index');
    $table['search_api_multi_index']['help'] = t('The search indexes that will be searched.');
    $table['search_api_multi_index']['type'] = 'options';
    $table['search_api_multi_index']['field']['handler'] = _search_api_views_field_handler('options', 'options');
    $table['search_api_multi_index']['field']['options'] = $indexes;
    $table['search_api_multi_index']['argument']['handler'] = 'SearchApiViewsHandlerArgument';
    $table['search_api_multi_index']['filter']['handler'] = 'SearchApiViewsHandlerFilterOptions';

I tried the patch in # 14.

Thanks to that. I was able to install the module without the error message (Call to undefined method SearchApiMultiViewsQuery) and crashing my website.

But when I choose the class "multi-indexes" in "add a server", I get a blank page where there is just a message:

"Please configure the used service"

And the button "create server" does not work. Please look at the image in attachment..

Any idea?

Edit: Solved! The patch wasn't well applied.. Actually this patch is working for me!

I had problems apply patch #14 also, it looks like it had been applied to a download from d.o (it had the version info etc) which is why it failed to apply for me. I've re-rolled it against 7.x-1.x. I've also added in a couple other fixes to views/search_api_multi.views.inc (from my best guess), where it was using $info, $fields and $orig_wrapper which weren't defined. I looked at the normal Search API views implementation to try and figure out what was needed where, and it seems to work now.

The only problem I have now is that it doesn't seem to work with aggregated fields... My aggregated field (which works fine in a non muli-index view) produces an error on the multi-index view:

Notice: Undefined index: default_node_index:search_api_aggregation_1 in SearchApiSolrService->searchMultiple() (line 1379 of sites\all\modules\search_api_solr\service.inc).

I think the problem is that the aggregated fields created on the index aren't being brought over to the 'multi index' or something like that. I was suprised that it was using the default SearchApiSolrService rather than the SearchApiMultiSolrService that the patch in #14 introduces... Not sure if that's where the issue is coming from and I wasn't quite sure where to tell it which service class to use.

To get aggregate fields etc going you need dev version of search_api_solr as committed here: #1604570: Aggregated fields ignored in searchMultiple
The patch at #18 only supports full-text filters for searching.
The attached patch adds support for all other filters, when adding the fields to views data, we need to reference the index machine name too so the fields line up with those returned in createFilterQueries logic in search_api_solr.
The difference between the two patches is as follows:

--- a/search_api_multi.views.inc
+++ b/search_api_multi.views.inc
@@ -81,7 +81,7 @@ function search_api_multi_views_data() {
       if ($id != $key) {
         $table[$id]['real field'] = $key;
       }
-      _search_api_views_add_handlers($key, $field, $tmp, $table);
+      _search_api_views_add_handlers($index->machine_name . ':' . $key, $field, $tmp, $table);
     }
 
     // Special handlers

Unfortunately, this still doesn't work for me as expected.

I've set up five indexes - two for different profile2 types, three for different node types - that work just fine in "single" index views. The profile2 indexes each include User>User ID fields, the node indexes each have their Node ID fields.

My multi index view should receive just these five ID fields. But with the patch from #18, when I want to add fields, I just find the node ID for one of these node types, and the user ID for one of the profile types; at least the node/profile type names are contained in the field labels, and I get resonable results.

Using #19, I see two "Indexed Node: User ID" and three "Indexed Node: Node ID" fields, which I can add, but then I'm only getting results where each of these IDs is 0.

I'm running:
search_api_multi 7.x-1.0-beta3+2-dev (incl. the patch from #18/#19)
search_api 7.x-1.2
search_api_views 7.x-1.2
search_api_solr 7.x-1.0-rc2+2-dev
views 7.x-3.3+195-dev

Could you please give me a hint?

Thanks for the help here!
However, there were still several things wrong with your patch. I've corrected some of them in the attached one, and also incorporated #1608356-4: Adapt Views integration to recent Search API changes. But one big issue is still open: the entire SearchApiMultiViewsQuery::get_result_wrappers() function is wrong – for example, it uses $row where it isn't even defined correctly, and many other issues.
Also, please post the service class as a patch over at the Solr project!

Any news on this? How far away is the views integration to be in sync with search_api? Is there a chance to get this work? I need to be able to search on a node index and a file index and show mixed results. I saw that this could be done by apache_solr but have still hope that this could work with search_api too.

Enabling the patched module works, but after enabling the module a drush cc all gives me an endless loop of

Undefined index: entity type entity.views.inc:215

I don't know where to start to find the problem. I guess it's related to search_api_multi_views_data().

But's too less documentation to understand what is going on. For example: What does this mean? It looks somehow wrong to me.

          // The real nesting level of the wrapper, not the accumulated one.
          $level = search_api_list_nesting_level($info['type']);
          for ($i = 0; $i < $level; ++$i) {
            $wrapper = $wrapper[0];
          }

There are other changes in #19, why aren't they in #21?

Without a little help I can't fix this. I am wondering if the Search API multi-index searches needs to be a separate module. Isn't it just a little difference in the search query to allow just one or multiple indexes?

Thanks to generous sponsoring by Itelios do Brasil I was finally able to tackle this issue concentratedly and came up with the attached solution.
It seems to work perfectly for me, please help me get this finally committed by testing!
Just beware that the way you'd access fields now has slightly changed, unindexed properties have to be made available by adding the corresponding index's search results via a relationship.
Also, since the internal naming scheme completely changed, previous views won't be usable anymore. Sorry, but this was unavoidable due to the changes in the Search API / Entity API (and writing an update function for this being a really, really bad idea).

Also, I posted my solution for the Solr problem over at #1815348: Fix queryMultiple() to not use item ID as the array key.

Committed.