Mailing-List: contact ruby-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ruby-dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of goodieboy@gmail.com
 designates 64.233.182.190 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=aRTtGkFObq3nK5prwIQH3+F4f1qNy92ixagidyMSSquf6Qt9uL+Oinqzc1nbKp1xgV
         z7VMwj44BJs1ZGMOKxSWH2NJgVZUhzwcEKg7QMSvpuzAPYV0jzw6ZX3DzcCUMohM5RbX
         QvUV1CiN4UL5WF5g50SomTvUzLwsSpvuKB8Sg=
Message-ID: <c66dcac40809291840m19b7b0aawf12d6a1fa20882cc@mail.gmail.com>
Date: Mon, 29 Sep 2008 21:40:42 -0400
From: "Matt Mitchell" <goodieboy@gmail.com>
To: ruby-dev@lucene.apache.org
Subject: Re: Ideas for simplifying solr-ruby and making it better
In-Reply-To: <48E10E60.5000206@r.email.ne.jp>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_24362_26752597.1222738842069"
References: <c66dcac40809281305u4fe1e6cax5fe1dfa54ebea5b@mail.gmail.com>
	 <48E003C1.2020301@r.email.ne.jp>
	 <c66dcac40809290637h23514f63l9d9de4693ddb77c4@mail.gmail.com>
	 <48E10E60.5000206@r.email.ne.jp>

------=_Part_24362_26752597.1222738842069
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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
>
>

------=_Part_24362_26752597.1222738842069--