How does it compare with acts_as_solr?

[vierund...@googlemail.com]

I'm not sure, if I'm getting the purpose of sunspot - how does it
compare to acts_as_solr (http://github.com/mattmatt/acts_as_solr) -
reinventing the wheel? Or a completely different approach? I'd rather
see the two projects join, then having two projects with very
overlapping features...

[Peer Allan]

About a year ago the official acts_as_solr was abandoned by the owner and to the best of my knowledge no one took up the reins (actually a friend of mine tried to and Thiago agreed but didn't give up the keys).  As a result acts_as_solr was forked like mad on github and your guess as good as mine as to which one is the "official" version.  There are several branches that are under active development but with little collaboration between those developers the web has gotten a little crazy.

I started looking into sunspot because the development was active, read a couple of articles on it (http://www.linux-mag.com/id/7341) and when I checked out the code it was very clean and easy to understand.  The maintainer is great too.  I added a couple of patches to improve indexing performance and Mat accepted them and got them into the official release within a  few hours.

I agree it would be nice to get the solr support under one roof, but frankly, I think it may be too late for that.  It would quite the job (think merb/Rails) to get them together.  The codebases are exceedingly different and getting the 20+ fork maintainers could be a daunting challenge.  Of course, they do say that nothing that's worth doing is easy!

Peer

[outoftime]

Great question. At a fundamental level, both Sunspot and acts_as_solr
aim to solve the same problem, which is to provide a Ruby API for Solr
interaction. My inspiration for creating Sunspot was frustrations with
the way acts_as_solr works; we currently use acts_as_solr in our
application, but have run into several elements of its architecture
that at best require nasty workarounds, and at worst limit what we can
do with it. So Sunspot is indeed reinventing the wheel, but my goal is
for this new wheel to provide a smoother, more enjoyable ride.

acts_as_solr has provided a great service to the Rails community by
making Solr integration easy, and I don't want to downplay that. My
life would certainly have been a lot more difficult if it hadn't been
available when my company was building out our application. But when
considering what an ideal solution would be, I determined that
acts_as_solr's architecture doesn't readily translate into what I had
in mind. I'll try to outline the differences below and give some
support for how the two libraries, underneath the hood, are quite
different.

First, there is an important difference in the way acts_as_solr and
Sunspot construct their respective Solr schemas (conf/schema.xml).
acts_as_solr makes a distinction between normal fields, which can be
typed or untyped, and "facet" fields. These are stored separately in
the index, but in a way that means that if you want to sort by a given
field and also facet by it, you have to define it twice. Solr itself
doesn't require that distinction. Further, acts_as_solr copies all
fields into the default fulltext field, which means that, for
instance, storing a category ID makes that number searchable by
fulltext as well. Sunspot, on the other hand, distinguishes between
fulltext fields, which are tokenized and searchable as fulltext, and
typed fields, which are non-tokenized, facetable, orderable,
restrictable, etc. This architecture keeps a clean separation between
fulltext-searchable fields and typed data used for scoping. This is
analogous to the distinction between "fields" and "attributes" that is
built into Sphinx.

Another important difference between Sunspot and acts_as_solr is that
acts_as_solr is a Rails plugin, and its architecture is tightly
coupled with ActiveRecord. Sunspot, on the other hand, is a standalone
Ruby library that is capable of indexing any Ruby object, if the
appropriate adapter is defined. Sunspot::Rails bridges the gap to make
Rails integration easy, but all of Sunspot's meat is applied to
indexing Ruby objects generally.

The final big difference is that acts_as_solr is much "closer to the
metal" of Solr itself - queries have to be sent in Solr/Lucene's
boolean syntax, and the results are returned verbatim as the big,
nested Ruby hash that Solr sends back (with the exception of loading
the result objects out of the database). Sunspot, on the other hand,
presents an API to build searches using pure Ruby, and returns the
search results as a structure of real Ruby objects.

Sunspot provides numerous other enhancements as well, but I'd say
those are the big ones. My impression is that acts_as_solr is very
popular and has helped countless Rails projects implement search, but
my hope is that in the future, as Ruby developers are considering how
best to integrate search into their applications, Sunspot provides the
best solution out there. Suggestions are very welcome!

Mat

On Jun 9, 4:37 am, "vierundsech...@googlemail.com"