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:
http://github.com/mwmitchell/slite/tree/master/lib/slite.rb
example:
http://github.com/mwmitchell/slite/tree/master/README
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
