In #1858018-6: support for 'search_api_multi', Chrummibei posted a way for supporting multi-index queries by just issueing several standard Search API queries. Since this is by no way service class-specific, I think we should just add that functionality to this module, allowing queries on any (enabled) Search API indexes the user wants. If all of the indexes for a specific query are on the same server, and that server supports the search_api_multi feature, then we can still use the searchMultiple() method like previously. Otherwise, we use the workaround. While probably considerably slower, especially when viewing pages more to the back of the results, it would still be a vast improvement to not being able to do that at all. We just have to let users decide whether it's worth it for them.
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | 2032451-13--cross_server_searches.patch | 71.59 KB | drunken monkey |
| #11 | 2032451-11--support_any_index.patch | 71.63 KB | drunken monkey |
| #10 | Screen Shot 2013-08-08 at 3.31.48 PM.png | 155.25 KB | ivansf |
| #8 | 2032451-8--support_any_index.patch | 68.42 KB | drunken monkey |
| #7 | 2032451-7--support_any_index.patch | 68.38 KB | drunken monkey |
Comments
Comment #1
drunken monkeyAttached is the patch I'd propose, which should be completely working and only lack a few changes to README.txt.
Since the workflow is now a bit different, with queries not being tied to a single server, this is of course a large API change.
Also, since there is now only one base table, existing views will become invalid. I tried to supply an update function, but it somehow doesn't work (though I don't know why). If someone has any idea in that regard, please help! Otherwise, we'd have to let users adapt their views manually, which probably means re-creating them.
Comment #2
Anonymous (not verified) commentedI applied the patch, and when adding in the fulltext field filter, I get the following error:
PHP Fatal error: Call to a member function getIndexes() on a non-object in sites/all/modules/contrib/search_api_multi/views/handler_filter_fulltext.inc on line 25
I've checked, and $this->query is uninitialized (the non-object from the message). I looked a little deeper, and $view->query is uninitialized when the SearchApiMultiHandlerFilterFulltext instance is created.
Should I be using a specific version of search_api/views or might something else be missing?
My current versions are:
search_api - 7.x-1.x-dev (July 18 2013)
views - 7-x.3.7
Comment #3
drunken monkeyHuh, that's very weird … Have you cleared the cache after applying the patch?
For me, everything works fine. Or, at least it does now that I've fixed an error I just spotted. Filters on the index still don't work completely, but it's probably more or less impossible to properly support those.
New patch attached (now excluding the update function which wasn't working anyways)!
Comment #4
realityloop commentedusing #3 I also get the error from #2 when trying to add a "Search: Fulltext search" filter $this->query is NULL when I try and debug it, this is alongside https://drupal.org/node/1858018#comment-7669229
Fatal error: Call to a member function getIndexes() on a non-object in /Users/brian/Sites/findapgapro-7.x/profiles/findapgapro/modules/contrib/search_api_multi/views/handler_filter_fulltext.inc on line 25Comment #5
drunken monkeyDo you mean you have both patches applied? Or what do you mean?
Please discuss everything regarding this workaround for multi-index searches on non-Solr servers here, this will definitely not be added to the DB Search module (unless there's a compelling reason for it).
And, as said, I sadly can't reproduce this error, for me everything works. Have you tried with the latest dev versions of all involved modules? And, I guess you have cleared all caches (some time ago it was sometimes needed twice for Views, maybe it's like that here)?
Comment #6
Anonymous (not verified) commentedI've applied the new patch - same results (Call to member function getIndexes() on a non-object...)
I tried this with views 7.x-3.7, and again with the latest dev - same thing.
search_api is 7.x-1.x-dev (July 18 2013)
Like I mentioned before, $this->query is not initialized in the SearchApiMultiHandlerFilterFulltext::getFullTextFields() call.
And what should initialize it, view::init_query(), never gets called anywhere in the request to add/edit a filter criteria field. Do you have changes to search_api itself that may have added a call to init_query() somewhere in the chain of SearchAPI parent classes of SearchApiMultiHandlerFilterFulltext? Or can you think of any other call that would be creating that query object on your end?
Comment #7
drunken monkeyAh, you're right! Sorry, I don't know why this worked for me before, but I can now definitely reproduce it. Please see the attached patch which should fix this again.
Also, when using the "Search: Fulltext search" contextual filter I get some notices like the following:
Notice: Undefined index: summary in options_validate() (line 427 of …/views/handlers/views_handler_argument.inc).Does anyone know what's up with that and how to fix it?
Comment #8
drunken monkeyRe-roll to match latest dev version.
Please test!
Comment #9
tyler-durden commentedI tried installing the patch in #8 to the latest Dev version, but I think it failed. I say "think" because I am not good at coding, and I have spent 2 full evenings trying to figure out how to apply a patch on my Windows PC (no shell access for me).
I'd like to help test this patch further, could someone verify if the patch in #8 works or not? It seems to have failed on 2 files in this module (I closed the program in frustration and don't remember which files).
How long before this can be added to the Dev version? That would be so much easier !!!
Thanks for working on this addition, hoping to help test it out soon.
Comment #10
ivansf commentedI enabled it and it shows "Multi-Index search" as a base table, which is fine, but the View is rendering all the results, regardless of the filters that I use. I am unable to do any sort of filtering to it using Full text search.
Attached is a screenshot showing a filter "applied" to the view already.
Comment #11
drunken monkeyOh god, I can't believe how long it took me to spot that idiotic error – let alone, that I made it in the first place.
However, should be fixed with the attached patch. Please test/review!
Comment #12
drunken monkeyAnyone wants to re-test and make sure this now works? It's a large change, after all … Would be great if someone could give a final "OK".
Comment #13
drunken monkeyI found a small bug myself:
NULLfor the searched fields should be resolved into all available fields in any case, not just when keys are given. It's arguably a bug in the service backend to look at the fields when no keys are given, but it's not forbidden, so we shouldn't just leaveNULLin there. Normal Search API queries do the same.Patch attached, please test!
Comment #14
drunken monkeyOK, I hope everything will work.
Committed.
Comment #16
kasperg commentedAccording to the README Search API Multi only supports Solr. The fact that this issue has been resolved seems to mean that is is no longer the case. How about updating the README accordingly?