lucene-ruby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: Ideas for simplifying solr-ruby and making it better
Date Tue, 30 Sep 2008 10:09:28 GMT
One other big wish list item I have for solr-ruby beyond gutting it  
and simplifying it to the bare essentials, is to make it JRuby-aware.   
When running with JRuby, the SolrJ library will be used and will allow  
the use of SolrServer such that an EmbeddedSolrServer can be used.  I  
suspect we can make this all seamless somehow such that MRI works fine  
over HTTP, and JRuby gets the advantage of being able to work really  
nicely with embedded Solr.


On Sep 30, 2008, at 5:49 AM, Erik Hatcher wrote:

> On Sep 29, 2008, at 9:40 PM, Matt Mitchell wrote:
>> In regard to the arbitrary query param issue. There are a few  
>> reasons why I
>> brought that up. The first is that there have been times where I  
>> wanted to
>> pass in something to Solr and solr-ruby hadn't yet supported it.  
>> Which means
>> there needs to be a continuous process of field mapping  
>> integration, at
>> least enough to keep up with the latest Solr param spec. Probably  
>> won't be
>> be a real problem, but it did happen to me once. Another issue is  
>> that,
>> sometimes I feel like the mapping gets in the way. Remembering all  
>> of the
>> Solr params is one thing, but then when you use solr-ruby you have to
>> remember a whole new set. Oh and the solr params are shorter :)
> Yeah, it was a bit over designed to have alias and be too clever  
> with parameter mappings from Ruby to HTTP.  I'd like to strip away  
> all the mappings and have solr-ruby in its most elementary API be  
> able to simply pass through parameters and get the raw Ruby response  
> data structure back.  Very quickly folks will want to build on top  
> of that to make things cleaner, but that is fine.
>> c.query(:q=>'battery  
>> operated', :fq=>'location:Chicago', :qf=>'title^0.5',
>> :fl=>'title, man, price')
>> # v.s.
>> c.query(:query=>'battery  
>> operated', :filter_queries=>['location:Chicago'],
>> :query_fields=>'title^0.5', :field_list=>['title', 'man', 'price'])
>> It'd be really nice to have the field mapping be optional, and even
>> better... plugable field mapping!
>  +1
> Note that the current Solr::Request::Select is pretty close to what  
> you're asking for here.
> One thing I want to really handle cleanly is custom request handler  
> mappings - making it trivial to request to any handler.  It's not  
> too bad now, but the paired Request/Response class structure needs  
> to go.
>> The current request classes in solr-ruby (Solr::Request::Dismax  
>> etc.) really
>> look like query field mappers to me, that's what the bulk of the  
>> code is
>> doing it seems. So imagine for a querying... the connection class,  
>> a simple
>> query method, and then something like the current  
>> Solr::Request::Standard
>> being thrown in as a plugable mapper?
> +1
>> Not to promote inheritence :) but if Solr::Connection provided raw  
>> query ->
>> HTTP, you could do something like:
>> MyConnection < Solr::Connection
>> def query(params)
>>   super map(params) # the real query method accepts only raw solr
>> params...
>> end
>> protected
>> def map(params)
>>   # convert my param structure to a raw solr query string...
>> end
>> end
>> But there are better ways to do this in Ruby!
> Solr::Connection does provide pretty raw operations to Solr.  Look  
> at Solr::Connection#post.  Pass in an object that has #handler,  
> #to_s, and #content_type methods in and you're off and running.  The  
> #to_s being the key to parameter mapping.
>> -- as an example, here is something I threw together a few weeks  
>> ago just to
>> get a feel for the minimal code needed for talking to solr. This is  
>> nothing
>> more than an experiment, hasn't been tested, and of course isn't a  
>> "real"
>> project!
>> lib:
>> example:
> Cute stuff, Matt!
> I think there are goodies to be mined from there for sure.
> How about using #method_missing on Connection such that  
> connection.whatever(:key => 'value') would call to the "whatever"  
> request handler?  That'd be cool.
> I'm not sure I agree with creating objects beyond the eval of the  
> Ruby response though.  At least not in the core of solr-ruby.  Let's  
> let the response from Solr itself be the only object a client really  
> needs.  Conversion to other objects can occur a layer above the  
> inner core of solr-ruby, such as acts_as_solr.
> Keep in mind we have access to to change Solr's response format to  
> suit solr-ruby's needs also.  And I can see some custom solr-ruby  
> classes coming into play that Solr's Ruby response would emit.
> 	Erik

View raw message