[sdx-developers] LuceneDocumentBase... encore

[Pierrick Brihaye]

Bonsoir,

Je viens de travailler un peu sur notre fameuse classe et... j'ai découvert des 
problèmes potentiels qui nécessitent à mon avis une discussion avant d'aller 
plus loin.

Voilà :

L'interface DocumentBase définit la méthode index(....) avec un 
IndexableDocument.
En revanche, elle définit la méthode delete(...) avec un Document.

On a là un parti qui serait tout d'abord à préciser. En effet, si on part avec 
une approche "dure" en typant tout sur IndexableDocument, on se prive de la 
possibilité d'ajouter ou détruire un document non indexable depuis la base de 
documents, ce qui serait dommage car, intellectuellement, il est tout à fait 
possible d'ajouter un document sans vouloir l'indexer (par exemple, ajouter un 
document attaché à un document indexable, pas forcément - encore - indexé 
d'ailleurs)

Si on part avec une approche "souple", on va devoir remanier la gestions des 
entités dans la look-up index. Voici pourquoi :

apparemment, chaque document entré dans une base fait l'objet d'une entité dans 
le look-up index, ce qui paraît tout à fait normal. MAIS les documents attachés 
nécessitent également la modification de l'entité du document owner ce qui, en 
l'état actuel du code et si je ne me trompe pas *n'est pas fait* dans delete ! 
On risque donc de se retrouver avec des entités incohérentes pour les documents 
indexables possédant des documents attachés.

A mon avis, et si on veut garder l'approche "souple", il faudrait donc revoir 
la gestion des entités des look-up index pour que les documents attachés 
stockent leur owner plutôt que l'inverse (actuellement, les owners stockent 
leurs documents attachés). Ca permet, entre autres, la comptage de références 
et, sans doute, plus de performance sur l'interrogation et le traitement des 
look-up index.

Autre problème potentiel, quoique moins grave :

index(...) appelle add(...). Si on a un document indexable avec documents 
attachés, ce add va également appaler add. Aucun risque de débordement de pile 
:-) mais ça gêne considérablement la séparation des tâches. Je décris la 
succession actuelle :

add de l'owner :
écriture de l'owner dans le repository
- add du document attaché :
- écriture du document attaché dans le repository
- écriture de l'entité de look-up du document attaché
[autant de fois qu'il y a de documents attachés]
écriture de l'entité de look-up de l'owner
écriture du search-index de l'owner

Je me demande si on ne devrait pas, lors d'un index (ou d'un delete 
d'ailleurs), créer une liste possédant autant d'entrées que nécessaires.

de documents à ajouter dans le repository (owners ou documents attachés)
d'entités à ajouter dans le look-up index (owners ou documents attachés)
d'entrées à ajouter dans le search index (owners seulement)

... et sauvegarder (ou détruire) tout ça.

Bien sûr, le terme "ajouter" est générique. Lors d'une mise à jour, la 
constitution de la liste est plus compliquée que ça.

Voilà. Le problème m'a semblé suffisament sérieux pour que je n'aille pas plus 
loin sans votre avis sur la question.

A+

Pierrick Brihaye
mailto:address@hidden