In my environment.rb I say the following:
MyModel.disable_ferret
puts MyModel.ferret_enabled?
The console works as expected:
script/console
false
MyModel.ferret_enabled?
=> false
I can then edit an instance, ferret remains disabled and the changes
are not immediately indexed.
However, when I start mongrel Ferret is initially disabled, but then
somehow becomes enabled again after the first request. I don’t
explicitly enable ferret anywhere.
Here is my ferret config for the model in question:
acts_as_ferret( { :remote => true, :index_dir => “#{AAF_INDEX}/
supplier”, :fields => { :supplier => { :store => :yes }, :name =>
{:store => :yes}, :private_description => {}, :title => {},
:ur
l => { :store => :yes }, :description => { :boost => 10.0 },
:su
pplier_id => { :store => :yes }, :supplier_name => { :boost => 10.0 },
:ke
ywords => { :boost => 10.0 }, :data => {}, :extract => {}, :city => {},
:st
ate => {} } } )
Does anyone have any idea what could reenable ferret?
Thanks,
Erik
On Wed, Sep 12, 2007 at 01:37:55PM -0400, Erik M. wrote:
=> false
I can then edit an instance, ferret remains disabled and the changes
are not immediately indexed.
However, when I start mongrel Ferret is initially disabled, but then
somehow becomes enabled again after the first request. I don’t
explicitly enable ferret anywhere.
is this happening in development or production mode? This might be an
issue with the class reloading done in development mode, where the class
is reloaded, but environment.rb isn’t parsed again.
Cheers,
Jens
–
Jens Krämer
http://www.jkraemer.net/ - Blog
http://www.omdb.org/ - The new free film database
That was the problem. Sounds obvious now. Thanks again.
Erik
Jens K. wrote:
On Wed, Sep 12, 2007 at 03:14:21PM -0400, Erik M. wrote:
That was the problem. Sounds obvious now. Thanks again.
Ok. Now how do you deal with this?
I’d probably do something like this in application.rb:
before_filter :disable_ferret if RAILS_ENV == ‘development’
def disable_ferret
MyModel.disable_ferret
end
Not nice but should do until aaf gets a proper config mechanism that
allows setting variables in environment.rb that are read whenever
acts_as_ferret is called.
While I think of it - maybe a simple :readonly => true switch for the
acts_as_ferret method would be even more straightforward instead of
calling MyModel.disable_ferret in environment.rb?
Cheers,
Jens
Hi
I also have problems disabling the indexing.
Can you please advice which is the better solution to choose?
Does the :readonly => true in the model works?
Where to place this code?
When there is no index yet, the index is created during the search
request. Right? Could arise problems with write locks during a search
request as well, when multiple users only executing a search not a save?
Thanks,
Mario
On Wed, Sep 12, 2007 at 03:14:21PM -0400, Erik M. wrote:
That was the problem. Sounds obvious now. Thanks again.
Ok. Now how do you deal with this?
I’d probably do something like this in application.rb:
before_filter :disable_ferret if RAILS_ENV == ‘development’
def disable_ferret
MyModel.disable_ferret
end
Not nice but should do until aaf gets a proper config mechanism that
allows setting variables in environment.rb that are read whenever
acts_as_ferret is called.
While I think of it - maybe a simple :readonly => true switch for the
acts_as_ferret method would be even more straightforward instead of
calling MyModel.disable_ferret in environment.rb?
Cheers,
Jens
–
Jens Krämer
http://www.jkraemer.net/ - Blog
http://www.omdb.org/ - The new free film database