Hi, i’ve a project in wich i have 2 different rails apps accessing the
same DB.
The backoffice, as usual, changes data.
The frontoffice has a search capabilities with acts_as_ferret
(paginated) for search.
Maybe this is a newbie question but, when i delete index and restart
front app all the articles are indexed, but the new one’s (via
backoffice) are not searchable.
Does acts_as_ferret indexes on change ops, like insert,delete, update?
Is that the reason why i can’t see the new ones?
Thanks in advance,
Miguel
On Tue, Jul 03, 2007 at 09:25:53PM +0200, Miguel Carvalho wrote:
backoffice) are not searchable.
Does acts_as_ferret indexes on change ops, like insert,delete, update?
Is that the reason why i can’t see the new ones?
Exactly. You should use aaf in your backoffice application, too. Keep in
mind to use the same acts_as_ferret settings (fields, analyzer and such)
as you do in your frontend app. And use the DRb server to avoid
collisions when both applications want to access the index.
In the end it doesn’t matter where you run your DRb server (frontend or
backoffice), but to me it seems good to keep the index in the backoffice
app since that’s where the data is created/changed.
Jens
–
Jens Krämer
webit! Gesellschaft für neue Medien mbH
Schnorrstraße 76 | 01069 Dresden
Telefon +49 351 46766-0 | Telefax +49 351 46766-66
[email protected] | www.webit.de
Amtsgericht Dresden | HRB 15422
GF Sven Haubold, Hagen Malessa
Hum, tks.
Anyway, it’s not desirable for us (for now) to have that implemented in
the backoffice. Is there a way of force reindex, for isntance, in a
rails cron?
Regards,
Miguel
Jens K. wrote:
On Tue, Jul 03, 2007 at 09:25:53PM +0200, Miguel Carvalho wrote:
backoffice) are not searchable.
Does acts_as_ferret indexes on change ops, like insert,delete, update?
Is that the reason why i can’t see the new ones?
Exactly. You should use aaf in your backoffice application, too. Keep in
mind to use the same acts_as_ferret settings (fields, analyzer and such)
as you do in your frontend app. And use the DRb server to avoid
collisions when both applications want to access the index.
In the end it doesn’t matter where you run your DRb server (frontend or
backoffice), but to me it seems good to keep the index in the backoffice
app since that’s where the data is created/changed.
Jens
–
Jens Kr�mer
webit! Gesellschaft f�r neue Medien mbH
Schnorrstra�e 76 | 01069 Dresden
Telefon +49 351 46766-0 | Telefax +49 351 46766-66
[email protected] | www.webit.de
Amtsgericht Dresden | HRB 15422
GF Sven Haubold, Hagen Malessa
On Wed, Jul 04, 2007 at 11:46:14AM +0200, Miguel Carvalho wrote:
Hum, tks.
Anyway, it’s not desirable for us (for now) to have that implemented in
the backoffice. Is there a way of force reindex, for isntance, in a
rails cron?
of course, just call Model.rebuild_index
Note that unless you use the DRb server this will truncate the index
used for searching and rebuilt it in place. With the DRb server the new
index is built in the background so searches won’t be affected.
Jens
–
Jens Krämer
webit! Gesellschaft für neue Medien mbH
Schnorrstraße 76 | 01069 Dresden
Telefon +49 351 46766-0 | Telefax +49 351 46766-66
[email protected] | www.webit.de
Amtsgericht Dresden | HRB 15422
GF Sven Haubold, Hagen Malessa
Ok, tks.
I’ve not configured or controlled the server in anyway. Just installed
the gems as in
http://www.railsenvy.com/2007/2/19/acts-as-ferret-tutorial .
I believe you’re talking about controlling the server as in
http://projects.jkraemer.net/acts_as_ferret/wiki/DrbServer .
I’m not sure of the differences.
Can you direct me to an article that explains that?
Thanks,
Miguel
Jens K. wrote:
On Wed, Jul 04, 2007 at 11:46:14AM +0200, Miguel Carvalho wrote:
Hum, tks.
Anyway, it’s not desirable for us (for now) to have that implemented in
the backoffice. Is there a way of force reindex, for isntance, in a
rails cron?
of course, just call Model.rebuild_index
Note that unless you use the DRb server this will truncate the index
used for searching and rebuilt it in place. With the DRb server the new
index is built in the background so searches won’t be affected.
Jens
–
Jens Kr�mer
webit! Gesellschaft f�r neue Medien mbH
Schnorrstra�e 76 | 01069 Dresden
Telefon +49 351 46766-0 | Telefax +49 351 46766-66
[email protected] | www.webit.de
Amtsgericht Dresden | HRB 15422
GF Sven Haubold, Hagen Malessa
On Wed, Jul 04, 2007 at 12:10:30PM +0200, Miguel Carvalho wrote:
Can you direct me to an article that explains that?
http://projects.jkraemer.net/acts_as_ferret/wiki/DrbServer pretty much
explains this, I thought 
Basically the DRb server serves as a central resource all index access
(search and updates) goes through. It therefore avoids locking and index
corruption problems that may occur when multiple processes try to update
the index at the same time (this may be the case if your live setup
consists of more than one mongrel or fastcgi handler).
The DRb server is part of acts_as_ferret, and you may choose to use it
or not depending on RAILS_ENV, i.e. specify only a config for the
production env in config/ferret_server.yml so aaf won’t need the server
in dev and test environments, but only in production.
Jens
–
Jens Krämer
webit! Gesellschaft für neue Medien mbH
Schnorrstraße 76 | 01069 Dresden
Telefon +49 351 46766-0 | Telefax +49 351 46766-66
[email protected] | www.webit.de
Amtsgericht Dresden | HRB 15422
GF Sven Haubold, Hagen Malessa
Jens, thanks a lot for your help.
Best Regards,
Miguel
Jens K. wrote:
On Wed, Jul 04, 2007 at 12:10:30PM +0200, Miguel Carvalho wrote:
Can you direct me to an article that explains that?
http://projects.jkraemer.net/acts_as_ferret/wiki/DrbServer pretty much
explains this, I thought
Basically the DRb server serves as a central resource all index access
(search and updates) goes through. It therefore avoids locking and index
corruption problems that may occur when multiple processes try to update
the index at the same time (this may be the case if your live setup
consists of more than one mongrel or fastcgi handler).
The DRb server is part of acts_as_ferret, and you may choose to use it
or not depending on RAILS_ENV, i.e. specify only a config for the
production env in config/ferret_server.yml so aaf won’t need the server
in dev and test environments, but only in production.
Jens
–
Jens Kr�mer
webit! Gesellschaft f�r neue Medien mbH
Schnorrstra�e 76 | 01069 Dresden
Telefon +49 351 46766-0 | Telefax +49 351 46766-66
[email protected] | www.webit.de
Amtsgericht Dresden | HRB 15422
GF Sven Haubold, Hagen Malessa