Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Relevant info (note to self for writing a readme):
URL: http://svn.apache.org/repos/asf/lucene/solr/trunk/src/java/org/apache/so...
Repository Root: http://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 903517
Node Kind: file
Last Changed Author: hossman
Last Changed Rev: 901342
Index: apachesolr/src/java/org/apache/solr/search/QParserPlugin.java
===================================================================
--- apachesolr/src/java/org/apache/solr/search/QParserPlugin.java (revision 10823)
+++ apachesolr/src/java/org/apache/solr/search/QParserPlugin.java (working copy)
@@ -32,6 +32,7 @@
PrefixQParserPlugin.NAME, PrefixQParserPlugin.class,
BoostQParserPlugin.NAME, BoostQParserPlugin.class,
DisMaxQParserPlugin.NAME, DisMaxQParserPlugin.class,
+ ExtendedDismaxQParserPlugin.NAME, ExtendedDismaxQParserPlugin.class,
FieldQParserPlugin.NAME, FieldQParserPlugin.class,
RawQParserPlugin.NAME, RawQParserPlugin.class,
NestedQParserPlugin.NAME, NestedQParserPlugin.class,
Comment | File | Size | Author |
---|---|---|---|
#44 | 713142-44.patch | 874 bytes | Nick_vh |
#41 | 713142-41.patch | 1.95 KB | Nick_vh |
#18 | apachesolr-edismax-support-2.patch | 5.45 KB | ygerasimov |
#16 | apachesolr-edismax-support.patch | 2.98 KB | ygerasimov |
#12 | apachesolr-713142-settings_for_handler_2.patch | 4.43 KB | ygerasimov |
Comments
Comment #1
pwolanin CreditAttribution: pwolanin commentedComment #2
pwolanin CreditAttribution: pwolanin commentedmore compact
Comment #3
jpmckinney CreditAttribution: jpmckinney commentedComment #4
pwolanin CreditAttribution: pwolanin commentedneed to add instructions to the README iwth details on building/patching Solr, and also add a config option to the module.
Comment #5
pwolanin CreditAttribution: pwolanin commentedThe repo has been reorganized for lucene/solr the code is now at:
http://svn.apache.org/repos/asf/lucene/dev/trunk/solr/src/java/org/apach...
see above rev.
Comment #6
ygerasimov CreditAttribution: ygerasimov commentedEdismax works nicely on solr 1.5 with adding requestHandler as per patch.
Are you going to patch QParserPlugin.java and build the same on solr 1.4? And for this you need to create documentation?
What kind of config option you think is needed in this case?
Comment #7
pwolanin CreditAttribution: pwolanin commentedThe patch above in #2 shows the configuration needed in solrconfig - you might want to make it the default handler.
I have already exported this .java file plus patched as shown above in the text at top and built Solr with this. It works pretty well.
Comment #8
ygerasimov CreditAttribution: ygerasimov commentedMaybe it can be nice idea to let user select any available handler?
I believe it is possible to parse XML document returned by http://localhost:8983/_solr_path_/admin/registry.jsp and get all options of QUERYHANDLERs. But really not sure whether it is reasonable for user to check anything except standard, dismax, edismax.
Please let me know your comments.
Comment #9
pwolanin CreditAttribution: pwolanin commentedThe user should not need to know anything about it in most cases - the admin should decide.
Comment #10
ygerasimov CreditAttribution: ygerasimov commentedI have added options in Advanced settings for choosing type of handler. Please review.
Comment #11
pwolanin CreditAttribution: pwolanin commentedno, I think that's really the wrong approach - and the names you list dont' even match what's in the solrconfig.
and we should never do this:
Comment #12
ygerasimov CreditAttribution: ygerasimov commentedYes. I haven't thought about solrconfig. Please review attached patch. Now I parse both solrconfig and response from Solr to get the list of available handlers. Will this do the job?
Comment #13
pwolanin CreditAttribution: pwolanin commentedseems like overkill - and 'dismax' is not the name of the handler we use by default at the moment.
I really feel like this is a rare enough use case that building a UI is overkill. How many people are going to build and deploy a custom Solr.war?
Lot of assumptions break if you switch to the standard handler, to the point where I don't think that is a good option.
Comment #14
ygerasimov CreditAttribution: ygerasimov commentedOne of the solutions for #270412: Partial-word search completion is just to switch to edismax handler or standard. That is why I thought it can be nice idea to let admin decide how he would like to behave. But if you think it is too much to give admin this opportunity and let him write the module that adds qt parameter in hook_apachesolr_modify_query, it is great.
Comment #15
pwolanin CreditAttribution: pwolanin commentedI think it might be useful to add a variable to define the default handler - that way you chould change it with a variable_set() instead of needing a hook implementation.
I would like to add info about edismax to the README or some other documentation.
Comment #16
ygerasimov CreditAttribution: ygerasimov commented@pwolanin Could you please guide how to add needed files to solr in order to compile it with edismax support? Here is patch with some basic description, but the part with adding files is missing in README.txt.
Comment #17
pwolanin CreditAttribution: pwolanin commentedLooking at the development log, one might want to try a rev or a few later than what I used, but to start, add this command before the patching command (remove the space after http which I added to skip the URL parser):
Also, I'd change this part of the patch:
we do NOT want 'dismax' as the default - we want to use the solrconfig.xml default. Something more like:
Comment #18
ygerasimov CreditAttribution: ygerasimov commentedThanks for fast response. I hope I put everything clear in README.txt. Please review.
Comment #19
pwolanin CreditAttribution: pwolanin commentedLooking at what Matt Butcher did for his Solr query library, it's worth looking at whether we can just set the defType=edismax rather than having to define a new named handler. That way would would not have to patch the solrconfig at all.
Comment #20
Nick_vhAny update on this yet?
Since we really need to update to the edismax handler because we'd like to search in seperate fields and this is only available in the standard handler and not in the dismax we'd like to take benefit of the edismax.
However, patching is still not something I prefer to do, certainly not when the maintainers are a bit hold back because there might be a better way? By setting the qt=edismax an undefined handler pops up.
Could you give some more info about the Matt Butcher sources? Or how to proceed?
Comment #21
Nick_vhJust to comment : I tried out the patch and everything seemed to work fine! :-)
Thanks for all the effort
Comment #22
pwolanin CreditAttribution: pwolanin commentedsee comment about defType in #19
Comment #23
scotjam CreditAttribution: scotjam commentedCan anyone point me to examples of sites using edismax?
I'd love to see how it improves the search experience, but a bit daunted about patching and rebuilding solr to try it out.
Comment #24
pwolanin CreditAttribution: pwolanin commentedWe have it on all sites using Acquia Search. For example: "http://www.drupalgardens.com/search/apachesolr_search/app*" rel="nofollow">http://www.drupalgardens.com/search/apachesolr_search/app*
Comment #25
jpmckinney CreditAttribution: jpmckinney commentedComment #26
pwolanin CreditAttribution: pwolanin commentedseems like setting defType works - that would be preferred
Comment #27
jpmckinney CreditAttribution: jpmckinney commentedWhat's the suggestion? To add a config var in the admin, that when set causes defType=edismax to be added as a Solr parameter in all requests? Or to have users set defType=edismax in a hook_apachesolr_modify_query, in which case this issue should be a support request.
Comment #28
pwolanin CreditAttribution: pwolanin commented@jpmckinney - the suggestion is to maybe to make it an opaque setting (not in the UI) for 6.x.
The nice thing about using defType instead of qt is that one does not need to alter the solrconfig.xml
Comment #29
pwolanin CreditAttribution: pwolanin commentedComment #30
jpmckinney CreditAttribution: jpmckinney commentedIs #270412: Partial-word search completion relevant?
Comment #31
pwolanin CreditAttribution: pwolanin commentedNote for 7.x (and 6.x-3.x when it's opened) I think we'll want this as a per-server setting.
Comment #32
trothwell CreditAttribution: trothwell commentedWhats happening here? I'd like to see some partial word searching happening, any suggestions? Should i roll the patch?
Comment #33
pwolanin CreditAttribution: pwolanin commented@Funke-Tom. Well, depends what you are using on the server side whether it will work at all. What Solr version are you running?
You're welcome to roll the patch - it's relatively trivial, though note comments about 7.x being per search environment.
Comment #34
trothwell CreditAttribution: trothwell commented@pwolanian, I'm running 6.x-1.5.
Comment #35
frognation CreditAttribution: frognation commentedThe patch from #18 works well on my local copy on my Mac! However, I'm having trouble with it on Ubuntu 9.10 on my live server. I was wondering if anyone can see something wrong I'm doing here:
I patched the files and rebuilt Solr according to the updated README, then I followed the instructions on this page http://www.nickveenhof.be/blog/setup-drupal-6-apache-solr-tomcat6-and-ub.... However, I'm getting an error only on my live server "HTTP Status 400 - unknown handler: edismax" (it says that it can't find the Apache Solr server in the UI, although the settings says it can see it fine)
Appreciate any help on this!
Comment #36
pwolanin CreditAttribution: pwolanin commented@Funke-Tom - What version of Solr are you running?
Comment #37
trothwell CreditAttribution: trothwell commented@pwolanin - Sorry i'm running 1.4.1.
Comment #38
Nick_vhSince we would be able to find out the version number #1336324: Get Solr version number to determine feature sets like facet ranges and location search we could actually allow this configuration option in the search environment if solr 3.4 is found.
Solr 1.4 would stay unsupported
Comment #39
Nick_vhChanging title
Comment #40
Nick_vhComment #41
Nick_vhJust made the change to handle dismax/edismax through configuration. The patch does not handle difference between solr 1.4 and 3.4 yet. It is tricky because at the time you are configuring the server there is nothing known yet about the server unless it is online?
Any ideas?
Comment #42
pwolanin CreditAttribution: pwolanin commentedI would only call addParam if the value is set - for unset do nothing.
Also, we should not add it to the UI - instead maybe a drush command to set and environment variable value?
Comment #43
Nick_vhChange to a apachesolr_variable_get and set
Comment #44
Nick_vhChanged to a apachesolr_environment_variable_get with a default fallback to the query itself.
If you know that a certain environment is 3.4+ or edismax is enabled you can 'as a site developer' add an option to the UI if you want. As a precaution towards site builders we will not add this option to the UI ourselves.
Comment #45
Nick_vhCommitted
Comment #46
Nick_vhComment #47
Nick_vhCommitted this exact patch to 6.x-3.x