Hi!
On 27.08.2008, at 20:20, Eric Schulte wrote:
Thanks for all the info, I just found a very good related discussion
from ruby-forum which I thought I'd share
http://www.ruby-forum.com/topic/137629
well, in this discussion there's (besides some useful information)
some pretty biased statements from several people who obviously must
have had a frustrating time with Ferret, or just didn't get it working
right out of the box and decided it was cheaper to make their clients
switch search technology (and possibly losing features) than to fix
their deployment. I never had somebody from engine yard contact me
regarding their massive ferret deployment problems, not sure how hard
they really tried to get over them.
Imho it's not very likely that it's Ferret's fault that, while all
around the world people are running ferret based apps fine, *every*
client of engine yard experiences the same set of problems...
So here's my very own biased opinion just to complete the picture :)
I use Ferret in several productive projects with several customers,
and also choose it for new projects like the soon-to-be-released new
full text search for the german selfhtml.org portal or the search
feature at www.fahrrad-xxl.de, which tightly integrates aaf with rdig
(shameless plug: selfhtml.org search will be powered by Stellr [1] ;-).
I have absolutely no problem with Ferret not being very actively
maintained, because it works for me just like it is. Honestly, I
*never* had ferret segfault in any one one of my own production apps.
(But I admit I saw it segfault in other places, maybe I just don't do
the right things to make it crash...)
So why do I stick to Ferret while others declare it a 'dead' project?
Ferret's flexibility and feature set plus the level of Rails
integration it offers by means of aaf is very unlikely to be reached
by any other combination of search engine lib + Rails plugin in the
near future.
Having that said, I'm really interested how the KinoSearch/Lucy stuff
will go on...
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. It's an
independent server indexing whatever you throw over the fence via http
+xml. That framework independence is a great plus under some
circumstances (and my Stellr project scratches exactly that itch in a
much more lightweight and undoubtedly less scalable manner), but
sometimes it's also a bad thing.
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). But even if you do that then you
have
a) half a java project (I don't want that)
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)
Not to speak of Sphinx here, which offers even less integration with
your Rails application because it's tied directly to the database and
doesn't support stuff like real incremental indexing. It's easy to be
several times faster when you leave out most of the features...
Of course there are lots of use cases where Sphinx or Solr are
perfectly valid choices, because their feature set suits the
requirements and/or you're comfortable with running a servlet
container in your production env and spreading your application logic
across several languages.
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 ;)
Cheers,
Jens
[1] http://rubyforge.org/projects/stellr
--
Jens Krämer
Finkenlust 14, 06449 Aschersleben, Germany
VAT Id DE251962952
http://www.jkraemer.net/ - Blog
http://www.omdb.org/ - The new free film database
_______________________________________________
Ferret-talk mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ferret-talk
