Ferret_server doesn't appear to be running

Bonjour,

Quelqu’un s’est il déja battu victorieusement avec script/ferret_server
?

$ sudo script/ferret_server -e production start
starting ferret server…

Bon, ça à l’air OK

$ sudo script/ferret_server stop
ferret_server doesn’t appear to be running

Bien non, il avait rien fait :frowning:

En googlant je m’aperçois que je ne suis pas le seul à me casser les
dents
là -dessus, mais pas de solution convaincante :-/

Qqun à une expérience de la question ?

BTW

D’autres retours d’expérience sur ferret/acts_as_ferret ?

Merci d’avance.


IciMarché fédère l’e-commerce de proximité
http://icimarche.fr

Salut. Je ne peux malheureusement pas t’aider sur Ferret. Mais à moins
d’etre obligé de maintenir une application “legacy”, je te conseille
de t’intéresser aux solutions de recherche utilisant Sphinx
(UltraSphinx / ThinkingSphinx). C’est actuellement les solutions de
recherche full-text les plus utilisées et maintenues.


Nicolas B. (Novelys)
http://workingwithrails.com/person/7296-nicolas-blanco

2008/9/22 philippe lachaise [email protected]:

En fait j’ai trouvé pour Ferret : ça marchait tout simplement comme
annoncé,
c’est moi qui interprétait mal ce que je voyais :slight_smile:

à moins d’etre obligé de maintenir une application “legacy”, je te
conseille de t’intéresser aux solutions de recherche utilisant Sphinx

J’ai fait un tour des solutions indexation/recherche et voici ce que
j’en
retire (ça n’engage que moi) :

  1. Pour l’indexation il y plusieurs possibilités ; toutes assorties de
    plugins :

a) Natif SGBD : mauvaise réputation de scalability et liés aux SGBD
particuliers (MySQL ou Postgres)

b) Ferret/acts_as_ferret : le plus connu, on en dit le meilleur et le
pire
c) acts_as_solr : impose d’embarquer un run-time java
d) Sphinx : super prometteur (prefs, scaling) mais cause directement Ã
la DB
e) Xapian/acts_as_xapian/ : pas trop exploré ; semble qu’il faut un cron
pour mettre-Ã -jour les index

  1. Ferret s’impose pour au moins cette raison :

Ferret est bien documenté et dispose même d’un bouquin :

Ce qui m’ennuie beaucoup avec Sphinx c’est qu’il n’est pas aussi intégré
Ã
ActiveRecord que Ferret (ou plus exactement que acts_as ferret)

Pour AAF peu importe que je lui demande d’indexer une colonne d’une
table ou
un attribut de mon modèle indépendant de la DB (e.g. le contenu d’un
document dont la DB ne contient que l’URL ou une valeur composée Ã
partir de
plusieurs colonnes)

Autre point en faveur de Ferret c’est à la base du C + Ruby, c.a.d c’est
un
produit 100% Rubyforge.
Sphinx, Xapian et autres sont language-agnostic, super si on fait du PHP
mais pour RoR c’est pas un plus contrairement à Ferret.

Enfin, il me semble (de ce que j’ai déjà potassé) que Ferret à de
l’avance
pour tout ce qui est Stemming et Filtres pour pas mal de languages (un
peu
plus que Anglais+Russe) ce qui est important pour une appli i18n.

Bref, on va parier sur AAF pour l’insatnt (fingers crossed :wink:


IciMarché fédère l’e-commerce de proximité
http://icimarche.fr

philippe lachaise a écrit, le 09/23/2008 09:40 AM :

En fait j’ai trouvé pour Ferret : ça marchait tout simplement comme
annoncé, c’est moi qui interprétait mal ce que je voyais :slight_smile:

à moins d’etre obligé de maintenir une application “legacy”, je te
conseille de t’intéresser aux solutions de recherche utilisant Sphinx

J’ai fait un tour des solutions indexation/recherche et voici ce que
j’en retire (ça n’engage que moi) :

Juste un petit retour sur Ferret au cas où. Je ne suis pas convaincu par
la scalabilité et l’intégration à ActiveRecord. J’ai rencontré deux
défauts dont un est corrigé à ma connaissance :

  • acts_as_ferret et ferret corrompaient l’index lors des accès
    concurrents. Pour éliminer le problème si je ne m’abuse un serveur a été
    mis au point pour éviter les locks qui ne marchaient pas et garantir
    qu’une seule tâche d’ajout dans un index tourne en même temps.
  • acts_as_ferret ne gérait pas les transactions d’ActiveRecord : si un
    objet est créé dans une transaction mais qu’un Rollback intervient,
    l’index est corrompu : il référence un objet qui a été éliminé lors du
    rollback. Je n’ai pas souvenir que ce problème ait été résolu.

Le dernier étant bloquant pour moi, j’ai dû éliminer Ferret et
développer une solution maison pour l’utilisation que j’en faisais : la
recherche de similitudes entre contenus textuels.
Pour le dernier problème, pour être robuste il faut soit :

  • un index en base pour profiter des rollbacks (globalement indexation
    plus lente),
  • des méthodes de recherche qui filtrent sur les contenus effectivement
    en base (recherche plus lente).

Lionel

acts_as_ferret et ferret corrompaient l’index lors des accès concurrents.
Pour éliminer le problème si je ne m’abuse un serveur a été mis au point
pour éviter les locks qui ne marchaient pas et garantir qu’une seule
tâche
d’ajout dans un index tourne en même temps.

C’est le fameux ferret_server avec lequel j’avais (de ma faute) un
problème.
Il vient avec AAF et tourne en DRb.

acts_as_ferret ne gérait pas les transactions d’ActiveRecord

Là je ne sais pas répondre…


IciMarché fédère l’e-commerce de proximité
http://icimarche.fr

Il existe pas un moyen pour mettre à jour Sphinx automatiquement qu’en
utilisant une task rake ?
Est-ce que quelqu’un a des bons retours sur cette problématique ?

Cordialement,
Pierre

On 23 sep, 10:48, “philippe lachaise” [email protected]