A query with lots of conditions (more than 100) will break Solr search due to it using 'GET' method instead of 'POST'.
The PHP library allows for using post instead of get, but the drupal module's interface doesn't. I've patched my version to using only post, not get, but I'm not sure of the implications (is it slower? are there other issues?). Perhaps the module should allow you to configure which method to use, or the post method might become the default.
In any case, attached is a patch that changes the method to use post instead of get.
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | large_solr_queries-1276970-15.patch | 1.68 KB | derhasi |
| #13 | large_solr_queries-1276970-13.patch | 1.69 KB | derhasi |
| #12 | search_api_solr-large-queries-break-solr-search-1276970-12.patch | 752 bytes | jsacksick |
| #11 | solr_queries_post-1276970-11.patch | 1.13 KB | webflo |
| #10 | solr_queries_post-1276970-10.patch | 1.13 KB | emorency |
Comments
Comment #1
moonray commentedAlso, see #1141488: Allow multiple values for contextual filters for reference.
Comment #2
drunken monkeyI'm not sure about the implications of changing this, either, to be honest. Just stole the code from the apachesolr guys, really. ;) But if you post this as a patch that makes the method configurable, I guess no-one should object to it being committed.
In any case, thanks for reporting this and tracking the bug down!
Comment #3
drunken monkeyComment #4
moonray commentedIt seems this issue was tackled in a different project (Apache Solr Search Integration) as well: #761990: 400 Bad Status if URL length limit exceeded
The patches to use as a template would be #39 (can be used as is, most likely).
Comment #5
moonray commentedSo, basically, if we follow the example of Apache Solr Search module, we'd have to duplicate the Apache_Solr_Service class.
Not sure how best to proceed from here... @drunken monkey?
Comment #6
drunken monkeyAh, OK, great. Seems like a good idea, just switching the method when necessary. Not sure whether to make this a server setting or just a hidden global variable – most people won't care about this, I guess. (On the other hand, they might run into problems exactly because of that, so maybe a bit of additional publicity for the potential problem would be good, too.)
In any case, should be a pretty easy patch. Would be great if you could provide it, otherwise you'll have to wait until I have more time available.
Comment #7
moonray commentedCare to outline how you would like this patch written? Are we duplicating the patch above (thus duplicating Apache_Solr_Service, which is part of the library in our module)?
Comment #8
drunken monkeyNo, we already have that override class,
SearchApiSolrConnection. Problem is just that directly overriding thesearch()method is probably not such a good idea (I specifically avoided overriding it in the past already), as it's a) not too uncomplicated and b) differs quite a bit between r22 and r60. Maybe we should just add a case in_sendRawGet()to use_sendRawPost()if the URL would be too long. I don't think that specifically using a GET request (even if the query would be larger than the set maximum) is such an important use case that we really have to preserve the method's contract in this edge case. (Otherwise, we could always add a way to override this override, saying „Yes, really use GET, no matter how long the query!“)And I think this should be an (advanced) option for each server.
Comment #9
modstore commentedI made the change to using post as per post #1, and it fixed my large query problem. Haven't found anything not working as yet.
Comment #10
emorency commentedI could not apply the patch from #1, here is a patch that can be applied on 7.x-1.x.
Comment #11
webflo commentedRerolled against 7.x-1.x
Comment #12
jsacksick commentedI think we should let the developer choose the method and keep by default the $_GET, but we may want to document that.
Here is a path proposal :
Comment #13
derhasi commented@webflo, jsacksick, the best solution I think would be to make it available as advanced option for the server. So the "developer" as well as a "site builder" could choose to create a second server configuration for "large" indexes.
The patch for that approach is attached.
Comment #14
tcmug commented#13 works beautifully.
Thank you.
Comment #15
derhasi commentedJust recognized a minor error for the default value. Fixed it in the attached patch.
Comment #16
drunken monkeyI did a bit of recherche and it seems there really is no reason not to use POST.
I still kept the configuration, now that it's there, but made POST the default and added a description saying that there's probably rarely a reason to change this.
Anyways, thanks for your work! Committed.
Comment #18
kenorb commentedThe bug is still not fully fixed, please follow this issue for details:
#1950402: Solr: 413 Status: Request Entity Too Large, when indexing the data [search_api_autocomplete]