One thing I really wanted to change in the 3.x solrconfig.xml, once Search API Solr got a dedicated one, was changing the default request handler to use the ExtendedDisMax query parser. This seems to unite all the advantages of the dismax parser (user-friendly, robust, matching across several fields) with those of the standard handler (advanced features like wildcards, range queries, …).

Has this been discussed in the Apachesolr module? If yes, with what conclusion?
Could we make this the default in our unified solrconfig.xml file? (Otherwise, of course, we can still always pass &defType=edismax with our queries.)

CommentFileSizeAuthor
#17 1606582-17.patch3.64 KBNick_vh
#16 1606582-13.patch3.63 KBNick_vh
#14 1606582-12.patch3.65 KBNick_vh
#12 1606582-11.patch2.71 KBNick_vh
#10 1606582-10.patch3.05 KBNick_vh
#6 solr-request-handler-differences.diff1.41 KBdrunken monkey
#4 1606582-4.patch4.97 KBNick_vh
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

cpliakas’s picture

cpliakas CreditAttribution: cpliakas commented

I believe we use EDismax for Acquia Search, so I am guessing that Apache Solr Search Integration uses this. Peter and Nick would have more knowledge that I here.

Nick_vh’s picture

Nick_vh
he/him
Location Ghent
CreditAttribution: Nick_vh commented

I'm ok with having edismax as default for the 3.x

I an imagine some confusions such as "my website works on dev but not in production", but hopefully documentation can help in that case. Perhaps the module should give a warning is someone is using Solr 1.4 that it would benefit from some features and speed if he would upgrade. (dismissible message)

cpliakas’s picture

cpliakas CreditAttribution: cpliakas commented

I think along these lines, Search API has some configs that set default parameters in it's request handler. If I am reading the configs right, these could be added application level as well? I am pretty sure this is the case, as I ended up adding them to the Acquia Search for Search API module so that it would function the same on top of our solrconfig.xml file. It seemed to work, but I wanted to see if we should move the default params to the application layer to help consolidate the solrconfig.xml file?

Nick_vh’s picture

Nick_vh
he/him
Location Ghent
CreditAttribution: Nick_vh commented
FileSize
1606582-4.patch4.97 KB

First try, we still end up with two request handlers. Could we move this to one request handler and do all the parameters in the modules?

cpliakas’s picture

cpliakas CreditAttribution: cpliakas commented

I would +1 the "do all the parameters in the modules" approach, with a second option of 2 request handlers if we cannot agree on the params in module approach.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
CreditAttribution: drunken monkey commented
FileSize
solr-request-handler-differences.diff1.41 KB

We can't set both of those to default="true", unless I'm mistaken.

Other than that, yes, I guess setting the individual options in the request would be a good approach.
Attached is a list of the differences between both request handler settings, as they are now. As can be seen, those are relatively small, only the highlighting parts differ really wildly. (More in the next comment, where I can use Dreditor magic …)

Also, as said, I'd be in favor of edismax as the defType (at least for the Search API).

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
CreditAttribution: drunken monkey commented
Status: Active » Needs work 
+++ b/conf/3.x/solrconfig.xml
@@ -1058,21 +1058,18 @@
-     <str name="echoParams">explicit</str>
-     <bool name="omitHeader">true</bool>
+     <str name="echoParams">none</str>

I don't know whether apachesolr needs the parameters echoed, but I'd surely have nothing against omitting the header.

+++ b/conf/3.x/solrconfig.xml
@@ -1058,21 +1058,18 @@
-     <str name="pf">
-        content^2.0
-     </str>
-     <int name="ps">15</int>
-     <str name="mm">1</str>
+     <str name="fl">item_id,score </str>
+     <int name="ps">100</int>

OK, based on the different schemas, these of course would differ.
With ps and mm I haven't really tested enough to say what parameters make more sense, or whether I'd be open to changing those of the Search API to the others.

Highlighting, as said, is the big difference. We'd really have to do that in the modules.

On the other hand, what does only having one request handler really buy us? Solr web hosters might even be glad to have the chance to modify these separately, and not having to deal with too many parameters set in code. With two handlers, we'd only have to send one different parameter each (also keeping the queries shorter …).

Also, if we'd stay with two handlers, I'd like mine with an underscore ("search_api"), to keep this uniformly.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
CreditAttribution: drunken monkey commented
Status: Needs work » Active
Nick_vh’s picture

Nick_vh
he/him
Location Ghent
CreditAttribution: Nick_vh commented

Tomas, great progress there.

Some idea for the separate handlers

I'd like a switch in the solrcore.properties that defines apachesolr=true and search_api=true (and/or false naturally).

Such properties can be used inside solrconfig.xml and schema.xml files by specifying an expression with optionally, a default value.

So using this syntax

<!-- xinclude fields -->
<xi:include href="../search_api.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>

and this if structure :

<xsl:if test="$solrcore.search_api">
  <xi:include href="../search_api.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
</xsl:if>
<xsl:if test="$solrcore.apachesolr">
  <xi:include href="../search_api.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
</xsl:if>

We could make it lean and mean and have separate config files for this. Just brainstorming anyhow.
Continuing with my movie now :)

Nick_vh’s picture

Nick_vh
he/him
Location Ghent
CreditAttribution: Nick_vh commented
FileSize
1606582-10.patch3.05 KB

New try, hurray munich sprint!

Nick_vh’s picture

Nick_vh
he/him
Location Ghent
CreditAttribution: Nick_vh commented
Status: Active » Needs review
Nick_vh’s picture

Nick_vh
he/him
Location Ghent
CreditAttribution: Nick_vh commented
FileSize
1606582-11.patch2.71 KB
drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
CreditAttribution: drunken monkey commented
Status: Needs review » Needs work

Looks great!

Just a few comments:

+++ b/conf/3.x/solrconfig.xml
@@ -849,6 +849,44 @@
+  <requestHandler name="pinkpony" class="solr.SearchHandler" default="true">

This should be hyphenated: pink-pony.

+++ b/conf/3.x/solrconfig.xml
@@ -849,6 +849,44 @@
+      <str name="echoParams">explicit</str>

I'd just leave that line out.

+++ b/conf/3.x/solrconfig.xml
@@ -849,6 +849,44 @@
+      <!-- Abort any searches longer than 4 seconds -->
+      <!-- <int name="timeAllowed">4000</int>  -->

+++ b/conf/3.x/solrconfig.xml
@@ -849,6 +849,44 @@
+      <!-- Abort any searches longer than 2 seconds -->
+      <int name="timeAllowed">2000</int>

Why only use this for MLT?
I'd deactivate it for both – if a site is running into this, the admin should just decide whether completely aborting is better. But having a fixed setting there for all sites, without knowing whether it will be appropriate , isn't such a good idea in my opinion.

Or we can use a variable instead. (Yes, I love those!)

Nick_vh’s picture

Nick_vh
he/him
Location Ghent
CreditAttribution: Nick_vh commented
FileSize
1606582-12.patch3.65 KB
Nick_vh’s picture

Nick_vh
he/him
Location Ghent
CreditAttribution: Nick_vh commented
Status: Needs work » Needs review
Nick_vh’s picture

Nick_vh
he/him
Location Ghent
CreditAttribution: Nick_vh commented
FileSize
1606582-13.patch3.63 KB
Nick_vh’s picture

Nick_vh
he/him
Location Ghent
CreditAttribution: Nick_vh commented
FileSize
1606582-17.patch3.64 KB
drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
CreditAttribution: drunken monkey commented
Status: Needs review » Reviewed & tested by the community

Go ahead! :D

Nick_vh’s picture

Nick_vh
he/him
Location Ghent
CreditAttribution: Nick_vh commented
Status: Reviewed & tested by the community » Fixed

Committed in accordance with drunkenmonkey, pwolanin and myself.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.