Avancé

Depuis Zend Framework 1.6, gestion des transformations de format d'index

Zend_Search_Lucene fonctionne avec les index Lucene Java 1.4-1.9, 2.1 et 2.3.

Le format actuel de l'index peut être obtenu par $index->getFormatVersion(). Ceci retourne une de ces valeurs :

Zend_Search_Lucene::FORMAT_PRE_2_1 pour le format 1.4-1.9.
Zend_Search_Lucene::FORMAT_2_1 pour le format 2.1 (utilisé aussi pour 2.2).
Zend_Search_Lucene::FORMAT_2_3 pour le format 2.3.

Les modifications de l'index n'arrivent que si une mise à jour de l'index est faite. Ceci arrive lorsqu'un nouveau document est ajouté à l'index, ou lors de l'optimisation manuelle de l'index par $index->optimize().

Dans un tel cas, Zend_Search_Lucene peut convertir l'index vers une version plus haute. Ceci arrive toujours pour le format Zend_Search_Lucene::FORMAT_PRE_2_1, alors transformé en format 2.1.

Vous pouvez gérer ces conversions et notamment le format d'arrivée avec $index->setFormatVersion(), qui prend comme paramètre Zend_Search_Lucene::FORMAT_2_1 ou Zend_Search_Lucene::FORMAT_2_3 :

Zend_Search_Lucene::FORMAT_2_1 ne fait rien puisque les format pre-2.1 sont convertis vers ce format (2.1)
Zend_Search_Lucene::FORMAT_2_3 force la conversion vers le format 2.3.

Les conversions vers des versions antérieure de formats ne sont pas supportées.

Note: Important!
Les formats ne peuvent pas être convertis vers des versions antérieures. Gardez une copie de sauvegarde si ceci s'avère nécessaire, car après une conversion il ne sera plus possible de faire marche arrière.

Utiliser les propriétés statiques de l'index

L'objet Zend_Search_Lucene utilise la méthode de destructeur pour valider ses changements et faire ses optimisations et nettoyages.

Il stocke les documents ajoutés en mémoire et les vide dans un segment sur le disque en fonction du paramètre MaxBufferedDocs.

Si la limite MaxBufferedDocs n'est pas atteinte, alors il y aura des documents non sauvegardés qui seront sauvés comme nouveau segment lors de la destruction de l'objet. La procédure d'optimisation automatique est lancée si nécessaire, cela dépend des paramètres MaxBufferedDocs, MaxMergeDocs et MergeFactor.

Les propriétés statiques d'un objet sont détruites après la dernière ligne de code exécutée.

class Searcher {
    private static $_index;
 
    public static function initIndex() {
        self::$_index = Zend_Search_Lucene::open('path/to/index');
    }
}
 
Searcher::initIndex();

Aussi, le destructeur est correctement invoqué à ce point de l'exécution du programme.

Un problème potentiel peut être les exceptions. Celles envoyées dans un destructeur d'un objet statique n'ont pas de contexte, car le destructeur est appelé après la fin d'exécution du script.

Vous pouvez alors voir une "Fatal error: Exception thrown without a stack frame in Unknown on line 0" au lieu de l'exception décrivant réellement le contexte.

Zend_Search_Lucene propose alors un détournement de ce problème avec la méthode commit(). Elle sauvegarde les changements et libère la mémoire utilisée pour stocker les segments. Vous pouvez utiliser la méthode commit n'importe quand, même plusieurs fois, pendant l'exécution de votre script. Vous pouvez aussi continuer à utiliser l'objet Zend_Search_Lucene pour rechercher, ajouter ou supprimer des document, même après une opération de commit (validation). L'appel à commit() est simplement une sécurité pour éviter les problème d'exception dans le destructeur de Zend_Search_Lucene :

class Searcher {
    private static $_index;
 
    public static function initIndex() {
        self::$_index = Zend_Search_Lucene::open('path/to/index');
    }
 
    ...
 
    public static function commit() {
        self::$_index->commit();
    }
}
 
Searcher::initIndex();
 
...
 
// Script shutdown routine
...
Searcher::commit();
...