On Aug 28, 2008, at 9:52 AM, Jens Kraemer wrote:
So here's my very own biased opinion just to complete the picture :)
Hey, software should be opinionated! That's totally fair :)
(shameless plug: selfhtml.org search will be powered by Stellr
[1] ;-).
Stellr - great name. Interesting... that's pretty sweet.
Solr, while being an interesting project without doubt, won't ever
reach the level of Rails integration that's possible with
acts_as_ferret, simply because it's server doesn't run in the
context of the rails app with model classes and all that stuff.
What advantage does Ferret have in terms of ActiveRecord integration
that Solr wouldn't have?
If you're talking about custom analyzers being in Ruby, more on that
below.
It's an independent server indexing whatever you throw over the
fence via http+xml.
Solr can index CSV as well now a relational database directly (with
the new DataImportHandler).
It also responds with Ruby hash structure (just add &wt=ruby to the
URLs, or use solr-ruby which does that automatically and hides all
server communication from you anyway).
How to use a custom analyzer with solr? You have to code it in Java
(or you do your analysis before feeding the data into java land,
which I wouldn't consider good app design).
Most users would not need to write a custom analyzer. Many of the
built-in ones are quite configurable. Yes, Solr does require schema
configuration via an XML file, but there have been acts_as_solr
variants (good and bad thing about this git craze) that generate that
for you automatically from an AR model.
But even if you do that then you have
a) half a java project (I don't want that)
That's totally fair, and really the primary compelling reason for a
Ferret over Solr for pure Ruby/Rails projects. I dig that.
But isn't Ferret is like 60k lines of C code too?!
and b) no way to use your existing rails classes in that custom
analyzer (I *have* analyzers using rails models to retrieve synonyms
and narrower terms for thesaurus based query expansion)
You could leverage client-side query expansion with Solr... just take
the users query, massage it, and send whatever query you like to
Solr. Solr also has synonym and stop word capability too.
However, there is also no reason (and I have this on my copious-free-
time-TOOD-list) that JRuby couldn't be used behind the scenes of a
Solr analyzer/tokenizer/filter or even request handler... and do all
the cool Ruby stuff you like right there. Heck, you could even send
the Ruby code over to Solr to execute there if you like ;)
Here's what I would do *if* I experienced severe problems with
Ferret in any of my projects:
Take aaf, replace Ferret with Lucene or even make it modular to
decide at run time which one to use, run the DRb server (or the
whole app, that depends) under JRuby and call it acts_as_lucene :-)
Et voila - great Rails integration plus Lucene's maturity. But as
long as Ferret's working fine for me that's really unlikely to
happen... Unless somebody wants to sponsor that project, of course ;)
Just using Solr and fixing up acts_as_solr to meet your needs (if it
doesn't) would be even easier than all that :) Solr really is a
better starting point than Lucene directly, for caching, scalability,
replication, faceting, etc.
I'd be curious to see scalability comparisons between Ferret and Solr
- or perhaps more properly between Stellr and Solr - as it boils down
to number of documents, queries per second, and faceting and
highlighting speed. I'm betting on Solr myself (by being so into it
and basing my professional life on it).
Erik
_______________________________________________
Ferret-talk mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ferret-talk
