Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

refactor single doc request TO SOLR to be /document rather than qt=document #96

Closed
MrDys opened this Issue Mar 13, 2012 · 10 comments

Comments

Projects
None yet
3 participants
Owner

MrDys commented Mar 13, 2012

CODEBASE-61: Since we'll probably be analyzing the solr logs, having cleaner urls will make the logs easier to parse. Also, this is a suggestion from Erik so it's probably right.

we don't want:

http://solr.baseurl/solr/select/?qt=document&id=666

but

http://solr.baseurl/solr/document?id=666

How:
change solrconfig request handler from "document" to "/document" and adjust solr_helper accordingly,

Owner

MrDys commented Mar 13, 2012

Original reporter: ndushay

Owner

MrDys commented Mar 13, 2012

jrochkind: I'd ideally like this to be flexible, and not require people to set up their solrconfig.xml a certain way, but allow Blacklight to work with multiple ways. Is this feasible?

Owner

MrDys commented Mar 13, 2012

jrochkind: bullk change, pushing past 3.1 in preperation for 3.0.

@MrDys MrDys closed this Mar 13, 2012

@cbeer cbeer was assigned Mar 13, 2012

Owner

cbeer commented Mar 13, 2012

erikhatcher: just checking.... do folks have handleSelect="true" in their BL solrconfig's? if not, you'll want to add it for upgrading to 3.6, since qt is used pervasively with BL I think. from the recent commit:

SOLR-3161: <requestDispatcher handleSelect="false"> is now the default. An existing config will 
probably work as-is because handleSelect was explicitly enabled in default configs. HandleSelect    
makes /select work as well as enables the 'qt' parameter. Instead, consider explicitly  
configuring /select as is done in the example solrconfig.xml, and register your other search    
handlers with a leading '/' which is a recommended practice.

@cbeer cbeer reopened this Mar 13, 2012

Owner

jrochkind commented Apr 2, 2012

This doesn't just apply to 'document' it applies to anytime we're sending a 'qt' right?

I think the change needs to be made at the Rsolr level, alas, and does not need to be made anywhere else. When we send a hash with a :qt in it to Rsolr, we need Rsolr to make the request to Solr using path for qt, not query param. Maybe>

We also possibly need to change our example Solr config to work properly, and tell people with existing solr configs what to change.

Owner

cbeer commented Apr 23, 2012

RSolr already has a mechanism for providing request handler paths, see
https://github.com/mwmitchell/rsolr-ext/blob/master/lib/rsolr-ext/client.rb#L15

Owner

jrochkind commented Apr 24, 2012

That's in Rsolr::Ext, not Rsolr by itself, don't know if that matters or not (at some points we've thought we wanted to move away from RSolr::Ext, toward pure RSolr, in part because Matt's not supporting RSolr::Ext anymore, including modifying it to keep it working with new versions of RSolr)

@cbeer cbeer closed this in b9c5371 Apr 24, 2012

Owner

cbeer commented Apr 24, 2012

We're still using the RSolr::Ext #find method at this point. though maybe we should consider bringing it into our own app some day..

Owner

jrochkind commented Apr 24, 2012

Hmm, I wonder if when resolving the issue on this ticket is the 'some day' to stop using Rsolr::Ext#find and bring the logic for that into BL (along with sending qt as path when appropriate), as one step toward reducing (rather than increasing) RSolr::Ext dependency. Not sure, just wondering.

Owner

jrochkind commented Apr 24, 2012

oops, except you went ahead and did it otherwise, okay then!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment