Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Lucene: ruby-dev

solr-ruby - let's get a 1.0!

 

 

Lucene ruby-dev RSS feed   Index | Next | Previous | View Threaded


goodieboy at gmail

Mar 13, 2009, 10:24 AM

Post #1 of 3 (3960 views)
Permalink
solr-ruby - let's get a 1.0!

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


mat at patch

Apr 6, 2009, 3:52 PM

Post #2 of 3 (3636 views)
Permalink
Re: solr-ruby - let's get a 1.0! [In reply to]

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.


goodieboy at gmail

Apr 9, 2009, 11:30 AM

Post #3 of 3 (3646 views)
Permalink
Re: solr-ruby - let's get a 1.0! [In reply to]

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 [at] patch> 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.
>
>

Lucene ruby-dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.