On Aug 30, 2006, at 1:36 PM, Yonik Seeley wrote:
I think Ruby is very fertile ground for Solr to pick up
users/developers right now.
I fully agree. Ferret is coming along very nicely as well, which is
wonderful for pure Rubyists that don't need the additional
dependency, skill set to manage, and different environment that Solr
would require. But Solr really shines for all its caching and index
management, so I'm sure there will be many RoR folks that will
embrace Solr.
Getting into some little details, it looks like a commit (which
actualy does an optimize) is done on every .save, right?
That's true. I'm not sure how one would avoid doing a commit for
a .save. There isn't, as far as I know, broader granularity for
database operations. An optimize wouldn't be necessary, but
certainly swapping over the searcher would be desired after a save.
I also notice that the commit is asynchronous... so one could do a
save, then do an immediate search and not see the changes yet, right?
That is true. But holding up a save for a new IndexSearcher would be
a big hit, at least in my application that currently takes 30+
seconds of warming up before a new searcher is ready.
I don't know anything about RoR and ActiveRecord, but hopefully there
is some way to avoid a commit on every operation.
It could certainly be made more manual such that a developer would
need to code in when a commit happens. I'm not currently sure what
other options there would be for it to be automatic but not done for
every .save. Within a RoR application, one could code in a <commit/>
a controller after_filter such that it would occur at the end of an
HTTP request by the browser. Any RoR savvy folks have suggestions on
this?
Erik
