[sdx-developers] RE : Métadonnées systèmes

[Martin Sévigny]

Bonjour,

> Aaaah. Je crois qu'on va s'entendre :-) On est donc d'accord 
> que la gestion des références sont *temporairement* codées en dur ?

Oui! :-)

> Intellectuellement, je trouve bizarre que l'on ait un haut 
> niveau spécifique à cause *d'un seul* sous-élément qui 
> l'est... Un père qui hérite de son enfant, quoi... Je 
> proposais donc une couche d'abstraction sur le SearchIndex de 
> façon à regénériciser son père, *étant entendu* qu'il y 
> aurait une forte variabilité dans les comportements 
> d'indexation selon les plate-formes sous-jacentes. A charge 
> pour les SearchIndexManagers de les gérer. Une DocumentBase 
> générique n'aurait eu qu'à transmettre la Query et à fournir 
> un objet chargé de recevoir les réusltats ou... une exception.

Soit. Le problème que j'ai actuellement, c'est de voir justement ce qui
est générique et spécifique à une recherche Lucene. Puisque SDX n'a
jamais fonctionné avec d'autres outils de recherche, il faut imaginer un
peu.

En imaginant avec Xpath/XMLDB, j'ai réalisé que c'était très différent à 
plusieurs niveaux (définition des champs/index, méthode
d'ajout/suppression, gestion des documents attachés, méthodes de
recherche, façons de présenter les résultats qui ne sont plus linéaires
mais hiérarchiques, etc.).

Bref, je n'ai à peu près rien trouvé de similaire... Suis-je aveugle?

> OK. C'est mon gros problème actuel. Ce que je voudrais, c'est 
> une succession d'évènements du genre :
> 
> beforeDocumentBaseAdd
>   beforeRepositoryAdd
>     repositoryAdd
>   afterRepositoryAdd
>   beforeReferenceAdd
>     referenceAdd
>   afterReferenceAdd
>   beforeIndexAdd
>     indexAdd
>   afterIndexAdd
> afterIndexAdd

Ca on l'a bien compris.

> Pas facile pour le moment parce que l'appel à index ne va pas 
> forcément générer un add (comportement de mise à jour défini 
> dans les paramètres d'indexation), mais bon, c'est normal. 
> Cela m'obligera à passer des paramètres pour signaler les 
> choix de stratégies faits par la DocumentBase aux 
> gestionnaires d'évènements.
> 
> Plus gênant encore dans ma problématique actuelle, comment je 
> fais pour accéder au XML d'indexation ? J'ai bien 
> IndexableDocument.GetFieldValues mais... c'est très typé 
> Lucene ce truc là :-) N'aurions nous pas plutôt là un 
> LuceneIndexableDocument ? Personnellement, je trouverais 
> intéressant de tout ramener en XML.

Le XML est virtuel dans le cœur de SDX, il est préférable de parler
d'événements SAX. Tu as un moyen (déjà fonctionnel) d'accéder à tes
données d'indexation. Tu crées une classe qui implante
fr.gouv.culture.sdx.pipeline.Transformation, et tu la mets dans le
pipeline d'indexation juste après ta XSLT d'indexation, donc en dernier.
Tu recevras le XML dont tu parles, tu n'as qu'Ã  faire ce que tu veux et
bien sûr le passer à ton consumer pour qu'il se rende jusqu'au bout.

Ensuite, lorsqu'on aura défini correctement ce que sont les événements
signalés lors de l'indexation, on peut faire quelque chose sur ces
données, je n'ai rien contre. Ce sera une deuxième façon.

> Moralité : XML peut-être partout :-)

Moralité : les événements SAX sont partout...

> Partant de là , je voudrais pouvoir disposer d'une interface 
> sur Document (car même les documents attachés peuvent avoir 
> ne serait-ce que des données système) me permettant d'accéder 
> à une vue XML de ces métadonnées Document.GetIndexation(), 
> Document.GetSystemMetadata.  Que ça me renvoie du DOM, du 
> SAX, du flux ou autre chose ne me dérange pas. Bien sûr, les 
> systemMetadata étant par définition définies par le système, 
> l'objet retourné devrait être en lecture seule... mais pas le 
> précieux document d'indexation que je m'empresserai de 
> modifier dans mon beforeIndexAdd :-)

Bref, tu l'as déjà pour les documents XML moins les données systèmes.

> Mmmh. Le problème est-il dans Lucene ? J'ai plusieurs soupçons : 
> - ressources système sur mon serveur Linux
> - problèmes dans la blackdown
> - SDX ! GetIndexReader, deleteIndexedDocument, getWriter, 
> releaseWriter ne sont pas synchronisées. Ne sachant pas 
> vraiment si c'est critique dans le cas d'une réindexation, 
> surtout avec des accès concurrentiels, je me demande s'il n'y 
> a pas là un problème.

La recherche pendant l'indexation est supposée être sans problème.

A bientôt,

Martin Sévigny