mwmitchell/rsolr-ext

An extension library for RSolr

rsolr-ext's Issues

:start param ignored in 1.0.3?

Previously Find would respect the inclusion of a :start param (rather than :page) but in v 1.0.3 the :start parameter is ignored if :per_page is specified. I think the cause is on line 18 of client.rb where you check for either a :page or a :per_page parameter.

Double 'rows' parameter to solr with RSolr 1.0.3

I have a RSolr::Client instance (managed through RSolr::Ext)

Blacklight.solr

#<RSolr::Client:0x00000105ce69d0 @uri=#<URI::HTTP:0x00000104878bd8 URL:http://127.0.0.1:8983/solr/>, @proxy=nil, @connection=#<RSolr::Connection:0x00000105d35418 @http=#<Net::HTTP 127.0.0.1:8983 open=false>>, @options={:url=>"http://127.0.0.1:8983/solr"}> 

When I add a :per_page parameter, the query to solr has two 'rows' parameters, which get interpreted as an array on the way back out and throw the following error:

Blacklight.solr.find :per_page => 10

INFO: [] webapp=/solr path=/select params={wt=ruby&start=0&rows=10&rows=10} hits=30 status=0 QTime=5

NoMethodError: undefined method `to_i' for ["10", "10"]:Array
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight/gems/rsolr-ext-1.0.3/lib/rsolr-ext/response.rb:27:in `rows'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight/gems/rsolr-ext-1.0.3/lib/rsolr-ext/response/docs.rb:8:in `extended'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight/gems/rsolr-ext-1.0.3/lib/rsolr-ext/response.rb:17:in `extend'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight/gems/rsolr-ext-1.0.3/lib/rsolr-ext/response.rb:17:in `initialize'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight/gems/rsolr-ext-1.0.3/lib/rsolr-ext/client.rb:24:in `new'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight/gems/rsolr-ext-1.0.3/lib/rsolr-ext/client.rb:24:in `find'
    from (irb):18
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@global/gems/railties-3.1.1/lib/rails/commands/console.rb:45:in `start'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@global/gems/railties-3.1.1/lib/rails/commands/console.rb:8:in `start'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@global/gems/railties-3.1.1/lib/rails/commands.rb:40:in `<top (required)>'
    from script/rails:6:in `require'
    from script/rails:6:in `<main>'

Thanks

rsolr-ext doesn't seem to work with current solr install

ruby-1.9.2-p136 :001 > require "rsolr-ext"
 => true 
ruby-1.9.2-p136 :002 > solr_connection = RSolr.connect
 => #<RSolr::Client:0x00000101988e68 @connection=#<RSolr::Connection:0x00000101988e90>, @uri=#<URI::HTTP:0x000001019de9d0 URL:http://127.0.0.1:8983/solr/>, @options={}> 
ruby-1.9.2-p136 :003 > puts solr_connection.luke['fields'].inspect
ArgumentError: wrong number of arguments (3 for 2)
    from /Users/mseeger/.rvm/gems/ruby-1.9.2-p136/gems/rsolr-1.0.0/lib/rsolr/client.rb:144:in `send_and_receive'
    from /Users/mseeger/.rvm/gems/ruby-1.9.2-p136/gems/rsolr-1.0.0/lib/rsolr/client.rb:222:in `method_missing'
    from /Users/mseeger/.rvm/gems/ruby-1.9.2-p136/gems/rsolr-1.0.0/lib/rsolr/pagination.rb:54:in `method_missing'
from /Users/mseeger/.rvm/gems/ruby-1.9.2-p136/gems/rsolr-ext-0.12.1/lib/rsolr-ext/client.rb:38:in `luke'
from (irb):3
from /Users/mseeger/.rvm/rubies/ruby-1.9.2-p136/bin/irb:16:in `<main>'

It works on gem 0.12.1

Facet items not working properly

Using Rails 2.3.2, Ruby 1.8.7, windows Vista, Solr 1.4

Playing with rsolr ext and have a query like this:

solr = RSolr.connect :url => 'http://localhost:8982/solr'

solr_params = {
:per_page=>2,
:queries=>':',
:facets=>{:fields=>['project_id_facet', 'source_type_facet']},
:echoParams => 'EXPLICIT'
}

@response = solr.find solr_params

In my view I have the code to output the facet values and counts:

<% @response.facets.each do |facet| %>

<%= facet.name %>

---

<% facet.items.each do |item| %>
<%= "#{facet.name}::#{item.value} (#{item.hits})" %>
<% end %>

<% end %>

With the stock code I get a result like:
source_type_facet
source_type_facet:: () source_type_facet:: () source_type_facet:: () source_type_facet:: () source_type_facet:: ()
project_id_facet
project_id_facet:: ()

The problem is in the facets method in RSolr::Ext::Response::Facets.

If I change this code:
(values_and_hits.size/2).times do |index|

items << FacetItem.new(values_and_hits[index_2], values_and_hits[index_2+1])

end

to:

values_and_hits.each do |key, value|

items << FacetItem.new(key, value)

end

I get the proper results:
source_type_facet
source_type_facet::ticket (4324) source_type_facet::commit (1092) source_type_facet::portal (34) source_type_facet::native (43) source_type_facet::build (211) source_type_facet::timesheet (7) source_type_facet::wiki (1127) source_type_facet::code_review (714) source_type_facet::general (266) source_type_facet::email (189)
project_id_facet
project_id_facet::1 (4637) project_id_facet::2 (1192) project_id_facet::3 (2178)

Anyone else see a similar issue?

If I inspect the value_and_hits variable its a simple hash like this:
{"1"=>4637, "2"=>1192, "3"=>2178}

So, I can't see how the original code can work at all.

facet limits

There is currently no way to actually set the "facet.limit" parameter when using facets

deprecation warning on response.docs

I see what you were trying to do, but this deprecation warning is really annoying. Every time I call response.docs, I get told:

warn "DEPRECATION WARNING: The custom pagination codebase in RSolr::Ext will no longer be supported. Use response.docs.will_paginate instead."

You see the problem here is that what it's suggesting I do instead is STILL calling response.docs! Calling response.docs.will_paginate will output the deprecation warning too. So even if I do what it's telling me to do, I still get the deprecation warning. And in fact, I get the deprecation warning on any call to response.docs, but the #docs method itself is NOT what you intend to deprecate. So there's no way to get rid of the deprecation warning. And it shows up all over the place in my logs, and in my output when running tests. It's really problematic.

Is there a better way to do this please? Including not outputting the deprecation warning. A deprecation warning that outputs even when you are NOT doing anything deprecated is just annoying.

will_paginate method undefined

This is probably a documentation issue instead of code issue.

When I use <%= will_paginate response.docs.will_paginate %> it gives me an error that method will_paginate is undefined in the docs array. This is the way your github documentation code example is recommending the line to be.

If I remove the method call at the end, everything works as expected.
So this works.
<%= will_paginate response.docs %>

Maybe your documentation needs to be updated?

question on deprecation re Rsolr::Ext.connect

When starting up a Blacklight app that uses RSolr::Ext, I get this:

"DEPRECATION WARNING: Future versions of RSolr::Ext will require initialization via RSolr::Ext.connect."

Can you explain what the deprecated behavior is exactly, and what the non-deprecated alternative is? How should I fix Blacklight code to not trigger this deprecation warning (and more importantly, be future-forward and not be using deprecated behavior).

Thanks.

Ruby 1.8.6 Issue

Ok, at this point this is a legacy issue, but it should be probably be recorded...

There's a "feature" introduced in ruby 1.8.7 in the Fixnum.times from requiring a block (1.8.6) and accepting a block (1.8.7+). This was causing an issue on 1.8.6 instances in the facets and has been fixed and verified for 1.8.6.

update rsolr-ext to work with spellcheck format of the Solr 1.4 release

Between 1.3 and 1.4 the format of the spellcheck results changed some. Simple results are returned by default. There are several options that can now be added on to return extended suggestions which include the frequency and/or collated suggestions.

I have created a fork where spellcheck is now tested. The mocks were taken from variations on the Solr wiki and the example Solr data. (http://wiki.apache.org/solr/SpellCheckComponent)

You can see the commit here:
http://github.com/jronallo/rsolr-ext/commit/d208f62c4ad19731b86e7dd2e9fd714659846d55

We are trying to upgrade Blacklight from a 1.4 prerelease/nightly to the Solr 1.4.1 release. You can see our ticket for that work here:
http://jira.projectblacklight.org/jira/browse/CODEBASE-241

I'd like to get this integrated into trunk rsolr-ext and ask that a new tagged release is made. I've bumped the patch level, but you may want to choose a different version number.

Please let me know what else I can do to get these changes in. I'll be sending a pull request.

Jason

Incorrect gemspec version

VERSION says 1.0.3, but rsolr-ext.gemspec says 1.0.2. gemspec needs updating.

simulates a will_paginate list insufficiently

I THINK (correct me if I'm wrong) the array returned by a Solr fetch when using RSolr::Ext is supposed to be simulate the array returned by will_paginate's paginate, so you can just pass the returned array to will_paginate for pagination.

In Blacklight we do pass in the returned array to will_paginate's methods, but we need to over-ride will_paginate's #page_entries_info to make it actually work with RSolr::Ext's results. I thought we were just over-riding it to change the formatting of the display, but I think our over-ride actually uses different accessors on the collection result object too.

The problem is, this means that once we've over-ridden it like this, you cant' use any of will_paginate's methods with anythign ELSE in that app, since #page_entries_info has been over-ridden to expect methods that are in RSolr::Ext's collection object, but NOT in will_paginate's own collection objects returned by #paginate.

See the definition of #page_entries_info in will_paginate here: https://github.com/mislav/will_paginate/blob/master/lib/will_paginate/view_helpers.rb

I was trying to return #page_entries_info in BL to a state where it'd reformat the string, sure, but still work with ordinary will_paginate collections too. But having trouble doing this, because I don't think RSolr::Ext's response object duck-types a will_paginate collection sufficiently.

In particular, as you can see from the original page_entries_info definition, a will_paginate collection has an #offset and an a #total_entries. But an RSolr::Ext does not. So we instead have to over-ride page_entires_info to ask for different things that RSolr::Ext DOES have, in the process breaking it for anything else.

(As a side comment relevant to BL but not neccesarily to RSolr -- the BL page_entries_info is looking at the @response instance variable instead of just the argument passed in, breaking it even MORE for any other use of will_paginate).

Double 'rows' parameter to solr with RSolr 1.0.3

I have a RSolr::Client instance (managed through RSolr::Ext)

Blacklight.solr

#<RSolr::Client:0x00000105ce69d0 @uri=#<URI::HTTP:0x00000104878bd8 URL:http://127.0.0.1:8983/solr/>, @proxy=nil, @connection=#<RSolr::Connection:0x00000105d35418 @http=#<Net::HTTP 127.0.0.1:8983 open=false>>, @options={:url=>"http://127.0.0.1:8983/solr"}> 

When I add a :per_page parameter, the query to solr has two 'rows' parameters, which get interpreted as an array on the way back out and throw the following error:

Blacklight.solr.find :per_page => 10

INFO: [] webapp=/solr path=/select params={wt=ruby&start=0&rows=10&rows=10} hits=30 status=0 QTime=5

NoMethodError: undefined method `to_i' for ["10", "10"]:Array
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight/gems/rsolr-ext-1.0.3/lib/rsolr-ext/response.rb:27:in `rows'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight/gems/rsolr-ext-1.0.3/lib/rsolr-ext/response/docs.rb:8:in `extended'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight/gems/rsolr-ext-1.0.3/lib/rsolr-ext/response.rb:17:in `extend'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight/gems/rsolr-ext-1.0.3/lib/rsolr-ext/response.rb:17:in `initialize'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight/gems/rsolr-ext-1.0.3/lib/rsolr-ext/client.rb:24:in `new'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@blacklight/gems/rsolr-ext-1.0.3/lib/rsolr-ext/client.rb:24:in `find'
    from (irb):18
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@global/gems/railties-3.1.1/lib/rails/commands/console.rb:45:in `start'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@global/gems/railties-3.1.1/lib/rails/commands/console.rb:8:in `start'
    from /Users/chris_beer/.rvm/gems/ruby-1.9.3-p0@global/gems/railties-3.1.1/lib/rails/commands.rb:40:in `<top (required)>'
    from script/rails:6:in `require'
    from script/rails:6:in `<main>'

Thanks