So,

my proposal is that as search modules evolve, it is in the interest of its users to provide less troubles in the backend. For example, the schema.xml and schema-3x.xml from Apache Solr also supports geo fields and any other field that search api might require.

Secondly, the solrconfig.xml from the apache solr module has been tested so it has the best tweaks regarding performance on a Solr 1.4 and Solr 3.x (http://www.nickveenhof.be/blog/upgrading-apache-solr-14-35-and-its-impli...)

on a third note, Acquia Search and Pantheon benefit from uniformity in schemas and this would improve support for both modules. (Regarding replication and scaling, the solrconfig needs tweaking, it's good that this can happen regardlessly from the module that is being used)

Lastly, I know that when search_api_solr was created they took the schema and solrconfig from the apachesolr module so it seems only logical that we update it with the latest knowledge and tweaks.

I'm attaching them here and hopefully we can do this change asap

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

BarisW’s picture

cpliakas’s picture

Title: Make the schema.xml exactly the same as the Apache Solr module. » Adopt common solrconfig.xml and schema.xml files for Apache Solr Search Integration and Search API Solr
Assigned: Unassigned » cpliakas

Changing title a bit to be more reflective of what needs to be done. In order to combine forces and determine the best Solr defaults for both projects, it would be worth attacking the solrconfig.xml file first as it probably will be the less disruptive consolidation in terms of application code changes.

To start, I am going to create a "patch" that consolidates comments so we can more easily analyze differences of actual directives to analyze them one at a time.

cpliakas’s picture

FileSize
28.43 KB

Attached is a starting patch that removed comment and other meaningless differences that have no bearing on functionality. As a starting point, this will allow us to more easily analyze the actual differences between the two projects' config files.

cpliakas’s picture

With the patch above applied to Search API Solr's solrconfig.xml, the attached patch shows the real differences between Search API Solr's solrconfig.xml file and Apache Solr Search Integration's solrconfig-solr3x.xml file.

To be clear, the minuses are stuff that is in Search API Solr's solrconfig.xml file, and the pluses are in Apache Solr Search Integration's solrconfig-solr3x.xml file.

cpliakas’s picture

Instead of discussing the differences here, I am posting a new project at http://drupal.org/sandbox/cpliakas/1600962 where the common configs can live and be discussed in separate issues as necessary. I feel that if we discuss everything here the thread will get real messy real quick.

Nick_vh’s picture

Let's revive this thread so we can make a patch that makes search_api_solr compatible with the changes in our common solr config thread

drunken monkey’s picture

Category: feature » task
Priority: Normal » Major

We will, in any case, have to replace all references to dismax with pinkPony.

Then, there is now no "standard" request handler anymore, but since we now use edismax "OR" queries should now work without problems, anyways. So the code that was previously there to switch the query type when OR was used (or the "direct" Search API query type) has to be removed.

I think there is also somewhere one (or maybe several) hard-coded assumption that type prefixes are always two characters long (except for text fields). With location and the like, this will have to change.
We might also have to adapt getFieldNames() and $type_prefixes (for the location fields, etc.).

Other than that, nothing really springs to mind. But I'd take a closer look over the module anyways before commiting this. If you want to implement the above changes I'd be grateful, though.
What necessary changes did you find?

drunken monkey’s picture

Status: Active » Needs work
FileSize
119.17 KB

A first draft, seems to work fine with 3.x.
Still to do: add 1.4 configs (see #1811038: Configs for 1.4), update README.txt.

The patch also contains fixes for the following other issues:
- #1744250: Support location based search
- #1789204: Add way to easily alter the fl parameter
And the following proposed changes to the configs:
- #1811988: Correct sortable version of Search API item ID field
- #1812302: Wrong "qt" default parameter for the PING handler
- #1812322: Whitespace

Please test with 3.x for now and tell me, if everything works!
(You have to re-index, of course.)

Nick_vh’s picture

+++ b/schema.xmlundefined
@@ -155,7 +153,7 @@
+    language-independent �€“ i.e., SynonymFilterFactory, StopFilterFactory and

some weird UTF8 quirk here

+++ b/schema.xmlundefined
@@ -386,4 +370,4 @@
\ No newline at end of file

newline, is this a common schema fault?

+++ b/solrconfig.xmlundefined
@@ -1096,4 +1083,4 @@
\ No newline at end of file

same newline problem here it seems

drunken monkey’s picture

All three come from the config files being removed, so I can hardly change that. ;) Or, rather, these shortcomings are therefore fixed anyways.

drunken monkey’s picture

Also includes proposed 1.4 configs (see #1811038-1: Configs for 1.4), README.txt still to do.

drunken monkey’s picture

Oops, here's the patch.

jonloh’s picture

I do see eDismax in place, but it still doesn't work with wildcard search.

facine’s picture

#12 works on my solr server 3.6.1

thanks!

drunken monkey’s picture

Status: Needs work » Needs review
FileSize
271.41 KB

I do see eDismax in place, but it still doesn't work with wildcard search.

Did you set the parse mode to “direct”? (Currently not available in Views, though.)

@ facine: Thanks a lot for testing!

Attached is a patch also containing the documentation changes, and not containing the other issues (which I just committed) anymore. Otherwise it's the same, so regarding testing it's exactly the same as above.

jonloh’s picture

Did you set the parse mode to “direct”? (Currently not available in Views, though.)

Just tried with Search API Pages and it seems fine in parse mode "direct". I guess the Views can't be used for this then :(

Thanks for the clarification drunken monkey!

drunken monkey’s picture

Status: Needs review » Fixed

I guess the Views can't be used for this then :(

That's actually an open feature request, which wouldn't be too hard to fix. So maybe soon …

Anyways, thanks a lot for testing!
Committed.

Status: Fixed » Closed (fixed)

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

michee.lengronne’s picture

I have these errors trying to apply the last patch:

error: patch failed: README.txt:30
error: README.txt: patch does not apply
error: patch failed: service.inc:396
error: service.inc: patch does not apply

checker’s picture

-comment removed