silverstripe/silverstripe-fulltextsearch

Solr 6 supported?

spekulatius opened this issue · 16 comments

Hello everyone,

has anyone used this in combination with Solr 6?

Cheers,
Peter

Not yet, but it would be great to support both 5 and 6.

Also, no we haven't used this with solr 5 either. It's a little behind. ;)

It could work near out of the box... all version-specific code should be abstractable.

Yep, we're running it on a project with Solr 6.1.0.
The code itself works out of the box, it's just the template file for types and the core config files that need updating.
We're using the extraspath in Solr::configure_server to specify a path to those files with a custom types.ss template in a class extending the SolrIndex class.
Credit for figuring how to change the core related files (solrconfig and types) goes to Alex Lawn from Catalyst. The rest just works.

Another thing with Solr 6+ is that it doesn't actually save the cores configuration as such. It uses an autodiscovery feature on every start to locate cores within a given path and it's subfolders. So it may be a bit tricky to configure the paths so that multiple cores can be discovered successfully for multiple websites within one server and maintain a reasonable level of file access at the same time.

Hey @zarocknz

if you have a spare moment maybe you could add your/Alex' findings here and open a PR? That would be amazing :)

Peter

Hi @spekulatius. As you probably know we just quickly hacked the Solr 4 version to work with Solr 6 rather than doing this properly, so I won't do a merge request for that.

Happy to share what Alex (our sys admin) figured out needed to be changed so it works with Solr 6.

In the conf/solr/4/extras/solrconfig.xml file we made the following changes...

  • Set version to 6 <luceneMatchVersion>6.0</luceneMatchVersion>
  • Changed all cases of class="solr.JsonUpdateRequestHandler to class="solr.UpdateRequestHandler"
  • Commented out <requestHandler name="/admin/" class="solr.admin.AdminHandlers" />

In the conf/solr/4/templates/types.ss file...

  • Deleted all cases of enablePositionIncrements="true"

Alex and I are not Solr experts, the above was just figured out by looking at the log and resolving the things it was erroring on. There will no doubt be a bit more work involved in supporting Solr 6 properly in this module while still allowing Solr 4 to be a valid option.

Note these changes are not compatible with the localsolr module, trying to run the search locally with these changes causes errors, most notably that lucene version 6 is unknown.

Cheers,
DouG.

Hey @zarocknz

cool, sharing this information is already great help for others. Maybe someone with more solr knowledge could verify this. Does anyone know someone?

Cheers,
Peter

@tractorcow Is there anything on the roadmap to add Solr v6.x (Currently v6.2.1) support - using at least the changes mentioned by @zarocknz as a starting point? Or are you looking for community-driven work based on a rough PR? Also, the docs (especially the README) have annoyed me for years so I'm happy to tidy this up as part of that or a different PR)....having said that I'm thinking few people would be keen on creating a new PR until some of the existing PRs have been dealt-to.

@phptek We're looking at something more community lead at the moment as our internal priorities are not on supporting solr 6 right now.

I'll take some responsibility for looking over existing PRs and any that you're kind enough to submit.

Awesome - I'm just hoping the reason for not looking at v6 isn't due to lack of Hamish's :-P

Nope. We just don't have an internal need for v6 as all our infrastructure is on v4 at the moment and not looking for upgrades at the moment.

It's definitely one of those "would likes", but those are much lower priorities than the must-haves unfortunately.

jaedb commented

Has there been any progress on this? We're looking at the best SilverStripe-friendly search engine to work with, and Solr seems to be the pick of the bunch. Unless there's a better recommendation? One that has more frequent updates?

@jaedb fulltextsearch/SOLR is certainly the most actively supported and used search module at the moment

jaedb commented

@robbieaverill Cool, thanks for that assurance. We've pushed as far as we can with complex direct database searching, but it has come time to get with the programme :-)

I'm going to close this issue as it's not a "bug". Solr 7 is now out and there are plans in the pipeline to look into supporting solr 7 but there are no timeframes we can commit to at the moment.

It'll likely require pulling out the Apache Solr PHP client and replacing it with solarium. It's not a small job but at least it'll mean a well maintained solr client library.

Hey @dhensby

understandable. Thanks for the update!

Cheers,
Peter