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
Comment | File | Size | Author |
---|---|---|---|
#15 | 1509380--common_configs-15.patch | 271.41 KB | drunken monkey |
#12 | 1509380--common_configs-12.patch | 214.48 KB | drunken monkey |
#8 | 1509380--common_configs-8.patch | 119.17 KB | drunken monkey |
#3 | refactored-1509380-3.patch | 28.43 KB | cpliakas |
#4 | apachesolr-diff-1509380-4.patch | 19.82 KB | cpliakas |
Comments
Comment #1
BarisW CreditAttribution: BarisW commentedFor reference, the old thread: #1130922: Use module without changing the schema.xml
Comment #2
cpliakas CreditAttribution: cpliakas commentedChanging 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.
Comment #3
cpliakas CreditAttribution: cpliakas commentedAttached 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.
Comment #4
cpliakas CreditAttribution: cpliakas commentedWith 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.
Comment #5
cpliakas CreditAttribution: cpliakas commentedInstead 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.
Comment #6
Nick_vhLet'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
Comment #7
drunken monkeyWe will, in any case, have to replace all references to
dismax
withpinkPony
.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?
Comment #8
drunken monkeyA 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.)
Comment #9
Nick_vhsome weird UTF8 quirk here
newline, is this a common schema fault?
same newline problem here it seems
Comment #10
drunken monkeyAll three come from the config files being removed, so I can hardly change that. ;) Or, rather, these shortcomings are therefore fixed anyways.
Comment #11
drunken monkeyAlso includes proposed 1.4 configs (see #1811038-1: Configs for 1.4), README.txt still to do.
Comment #12
drunken monkeyOops, here's the patch.
Comment #13
jonloh CreditAttribution: jonloh commentedI do see eDismax in place, but it still doesn't work with wildcard search.
Comment #14
facine CreditAttribution: facine commented#12 works on my solr server 3.6.1
thanks!
Comment #15
drunken monkeyDid 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.
Comment #16
jonloh CreditAttribution: jonloh commentedJust 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!
Comment #17
drunken monkeyThat's actually an open feature request, which wouldn't be too hard to fix. So maybe soon …
Anyways, thanks a lot for testing!
Committed.
Comment #19
michee.lengronneI 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
Comment #20
checker CreditAttribution: checker commented-comment removed