lucene-ruby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jamie Orchard-Hays <ja...@dangosaur.us>
Subject Re: Ideas for simplifying solr-ruby and making it better
Date Tue, 30 Sep 2008 02:40:56 GMT
Matt, I think that that is a great idea. Really useful.


On Sep 29, 2008, at 9:40 PM, Matt Mitchell wrote:

> Hi Koji. Thanks for the feedback!
>
> 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 :)
>
> 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!
>
> For the class placeholder issue... if we first start with the request
> classes, we see there is a :response_format, :content_type, and  
> a :handler.
> The rest of the data is essentially query param stuff (field  
> mapping). To
> make it really simple, the :handler could dissapear, it'd just be  
> set in the
> method ('select' for a :query or :search, 'update' for a :delete  
> etc.). The
> :response_format could be set based on the :wt value. And  
> the :content_type
> could be a preset attribute in the connection instance. So, with  
> that, you
> just provide a method that accepts a hash of params.
>
> 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?
>
> 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!
>
> Matt
>
> -- 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:
> http://github.com/mwmitchell/slite/tree/master/lib/slite.rb
>
> example:
> http://github.com/mwmitchell/slite/tree/master/README
>
>
>>
>>> * ability to pass in arbitrary query fields directly to solr without
>>> worrying about solr-ruby raising an error
>>
>> Why do you need this ability?
>>
>> Other than those above, I think you show good things up
>> to start our discussion and they are interesting.
>> I'd like to get comments/feedbacks from my associate (rubyist).
>>
>> Cheers,
>>
>> Koji
>>
>>


Mime
View raw message