solr-ruby - let's get a 1.0!

[goodieboy]

Solr-Ruby folks,

A while ago, I started some discussions about updating solr-ruby. Some of
the things I brought up were related to the way that solr-ruby handles param
mapping and response/request handling. Other folks have expressed the need
for jRuby support.

In an effort to get some development happening on this front, Erik Hatcher
created a refectoring branch within the solr-ruby repo. I ended up doing my
own development in a github repository because I had all kinds of nutty
ideas, and didn't want to bombard Erik with patches.

I now have what I'm considering to be a very solid code base, complete with
jRuby support. This library does no param mapping, and no request/response
class mapping; what you put in is what Solr gets, and what Solr returns is
what you get. In addition, it features a http adapter layer, so you can
switch between different http client implementations. The built in adapters
are Net::HTTP and Curb. Etc..

I'm asking the solr-ruby community (YOU!) to please have a look at this
library and offer your thoughts/opinions on it's capabilities and design. Do
you seen this as a possible refectored base for solr-ruby? Is there anything
there that you think could benefit solr-ruby? What are your thoughts on
getting solr-ruby to a 1.0 release?

Here's the library I've been working on:
http://github.com/mwmitchell/rsolr/tree/master

Thanks!

Matt

[outoftime]

Hi all - just wanted to give a big +1 to Matt on this one. I've been working for a while on a higher-level Solr library in Ruby called Sunspot that allows easy indexing/searching of Ruby objects (using a prepackaged schema.xml, etc), abstracting all Solr/Lucene syntax away from the API consumer.

The current (incomplete) version is built on solr-ruby, but a while ago I came across the LocalSolr plugin and thought it would be lovely to include LocalSolr support in Sunspot. I began looking for an alternative to solr-ruby that would allow me to cleanly use parameters and query types that aren't part of Solr core, and ran across RSolr. I think passing params through transparently is absolutely the right approach here - thus developers of higher-level APIs, or application developers who want to interact directly with Solr at a low level, are free to add integration with whatever Solr extensions they might need, without any explicit support from the Solr adapter layer.

Having the option of using curb with no extra effort is also a huge bonus.

One thing I'd like to see in RSolr/solr-ruby 1.0 is an object-oriented approach to building documents - in particular, it would be nice to have fine-grained control over field boost and that sort of thing, and having an explicit Document object would be an intuitive way to do that. Here's a simple example from an email discussion (that's been on hold for a few weeks - sorry Matt!) that Matt and I have been having:

  doc = RSolr::Document.new
  doc.id = 12
  doc.add_field('title_s', 'My Title', :boost => 2.0)
  solr.add(doc)

It would make sense to me to have this be RSolr/solr-ruby's internal representation of documents, with appropriate conversion from the simpler hash format when that is sufficient for API users' expression of documents. If time allows, I'm hoping to contribute a patch to RSolr to this effect in the near future, but of course it would be interesting to hear everyone's thoughts.

If anyone's curious, Sunspot is at http://github.com/outoftime/sunspot - comments, criticism, etc. more than welcome.

Thanks!
Mat

goodieboy wrote:

Solr-Ruby folks,

A while ago, I started some discussions about updating solr-ruby. Some of
the things I brought up were related to the way that solr-ruby handles param
mapping and response/request handling. Other folks have expressed the need
for jRuby support.

In an effort to get some development happening on this front, Erik Hatcher
created a refectoring branch within the solr-ruby repo. I ended up doing my
own development in a github repository because I had all kinds of nutty
ideas, and didn't want to bombard Erik with patches.

I now have what I'm considering to be a very solid code base, complete with
jRuby support. This library does no param mapping, and no request/response
class mapping; what you put in is what Solr gets, and what Solr returns is
what you get. In addition, it features a http adapter layer, so you can
switch between different http client implementations. The built in adapters
are Net::HTTP and Curb. Etc..

I'm asking the solr-ruby community (YOU!) to please have a look at this
library and offer your thoughts/opinions on it's capabilities and design. Do
you seen this as a possible refectored base for solr-ruby? Is there anything
there that you think could benefit solr-ruby? What are your thoughts on
getting solr-ruby to a 1.0 release?

Here's the library I've been working on:
http://github.com/mwmitchell/rsolr/tree/master

Thanks!

Matt

[goodieboy]

So others know... RSolr had some of the object oriented document code
underneath the covers. But just a few days ago, Mat generously created a
patch to expose the option of adding document objects instead of hashes
only. Thanks Mat! Have you had a chance to check out the latest version?

I think that RSolr now looks a lot like what we talked about here:
http://markmail.org/message/ujesla5hdgch7xrd

I hope that people will continue to give feedback. Any other ruby+solr users
out there?

Matt

On Mon, Apr 6, 2009 at 6:52 PM, outoftime <mat@...> wrote:

>
> Hi all - just wanted to give a big +1 to Matt on this one. I've been
> working
> for a while on a higher-level Solr library in Ruby called Sunspot that
> allows easy indexing/searching of Ruby objects (using a prepackaged
> schema.xml, etc), abstracting all Solr/Lucene syntax away from the API
> consumer.
>
> The current (incomplete) version is built on solr-ruby, but a while ago I
> came across the LocalSolr plugin and thought it would be lovely to include
> LocalSolr support in Sunspot. I began looking for an alternative to
> solr-ruby that would allow me to cleanly use parameters and query types
> that
> aren't part of Solr core, and ran across RSolr. I think passing params
> through transparently is absolutely the right approach here - thus
> developers of higher-level APIs, or application developers who want to
> interact directly with Solr at a low level, are free to add integration
> with
> whatever Solr extensions they might need, without any explicit support from
> the Solr adapter layer.
>
> Having the option of using curb with no extra effort is also a huge bonus.
>
> One thing I'd like to see in RSolr/solr-ruby 1.0 is an object-oriented
> approach to building documents - in particular, it would be nice to have
> fine-grained control over field boost and that sort of thing, and having an
> explicit Document object would be an intuitive way to do that. Here's a
> simple example from an email discussion (that's been on hold for a few
> weeks
> - sorry Matt!) that Matt and I have been having:
>
>  doc = RSolr::Document.new
>  doc.id = 12
>  doc.add_field('title_s', 'My Title', :boost => 2.0)
>  solr.add(doc)
>
> It would make sense to me to have this be RSolr/solr-ruby's internal
> representation of documents, with appropriate conversion from the simpler
> hash format when that is sufficient for API users' expression of documents.
> If time allows, I'm hoping to contribute a patch to RSolr to this effect in
> the near future, but of course it would be interesting to hear everyone's
> thoughts.
>
> If anyone's curious, Sunspot is at http://github.com/outoftime/sunspot -
> comments, criticism, etc. more than welcome.
>
> Thanks!
> Mat
>
>
> goodieboy wrote:
> >
> > Solr-Ruby folks,
> >
> > A while ago, I started some discussions about updating solr-ruby. Some of
> > the things I brought up were related to the way that solr-ruby handles
> > param
> > mapping and response/request handling. Other folks have expressed the
> need
> > for jRuby support.
> >
> > In an effort to get some development happening on this front, Erik
> Hatcher
> > created a refectoring branch within the solr-ruby repo. I ended up doing
> > my
> > own development in a github repository because I had all kinds of nutty
> > ideas, and didn't want to bombard Erik with patches.
> >
> > I now have what I'm considering to be a very solid code base, complete
> > with
> > jRuby support. This library does no param mapping, and no
> request/response
> > class mapping; what you put in is what Solr gets, and what Solr returns
> is
> > what you get. In addition, it features a http adapter layer, so you can
> > switch between different http client implementations. The built in
> > adapters
> > are Net::HTTP and Curb. Etc..
> >
> > I'm asking the solr-ruby community (YOU!) to please have a look at this
> > library and offer your thoughts/opinions on it's capabilities and design.
> > Do
> > you seen this as a possible refectored base for solr-ruby? Is there
> > anything
> > there that you think could benefit solr-ruby? What are your thoughts on
> > getting solr-ruby to a 1.0 release?
> >
> > Here's the library I've been working on:
> > http://github.com/mwmitchell/rsolr/tree/master
> >
> > Thanks!
> >
> > Matt
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/solr-ruby---let%27s-get-a-1.0%21-tp22501321p22919097.html
> Sent from the Lucene - Ruby Developer mailing list archive at Nabble.com.
>
>