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

[Pierrick Brihaye]

Salut,

Martin Sévigny wrote:

> 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.

On est d'accord.

> 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.).

Pour les champs/index, on peut postuler que le format actuellement
défini est le coeur même de SDX, non ? Ca devrait donc se mapper sur
Lucene ou sur n'importe quoi d'autre. Mais bon, si tu pouvais préciser
ta pensée...

Pour l'ajout ou la suppression, c'est moi qui semble être aveugle. En
quoi est-ce différent ? Idem pour les documents attachés.

Pour les méthodes de recherche, on est d'accord.

Et pour les résultats, il semble que je sois encore aveugle... Pourqoi 
ne serait-on plus en linéaire ?

>>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.

J'en suis sûr. Ce n'est malheureusement pas aussi simple car c'est très
fortement contextualisé : imaginons un remplacement : On détruit
l'ancien document, on ajoute le nouveau, on detruit son ancienne 
reférence, on recrée la nouvelle (la même en l'occurence), on détruit 
son index, on ajoute son nouvel index. La magnifique succession
d'évènements décrite ci-dessus devient fortement perturbée...

> Le XML est virtuel dans le coeur de SDX, il est préférable de parler
> d'événements SAX.

Oui. J'avais d'ailleurs dit que sa forme m'importait peu sachant
pertinement que c'était SAX qui s'imposait. Mon idée est donc de choper 
le SAX de l'indexation et de le réinjecter, avec quelques éléments 
supplémentaires, au moteur de persistence de l'index.

> 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.

Sur le papier, je pense avoir compris. Il va maintenant falloir mettre 
ça en oeuvre. Demandes de support garanties :-)

>>Mmmh. Le problème est-il dans Lucene ? J'ai plusieurs soupçons :

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

Même si une query appelle getSearcher (non synchronisée) pendant que la 
réindexation effectue périodiquement des resetSearcher ?  De toutes 
façons, mon problème actuel, c'est un plantage de la JVM lors d'une 
réindexation (probablement dès le premier lot). Le fameux bug 
4F530E43505002CC que Sun refuse de voir :-)

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden