Re: [sdx-developers] RE : documentbase

[Pierrick Brihaye]

Re,

Petites précisions :

> Mmmh... je ne crois pas. Quand on est dans une LuceneDocumentBase, on stocke 
> l'index de recherche avec Lucene *et* >les métadonnées sytème également avec 
> Lucene. Ce que je voudrais, c'est une *délégation* du style de celle des 
> >repositories que, je le répète, trouve excellente. On pourrait avoir un 
> LuceneMetadataManager (qui à l'heure actuelle est >complètement encapsulé 
> dans la LuceneDocumentBase), un JDBCMetadataManager etc. De le même façon, on 
> pourrait >avoir également un LuceneSearchIndexManager (encapsulé lui-aussi), 
> un JDBCSearchIndexManager...

> Les noms sont bien sûr indicatifs ! Mais bon, pour moi, on a un modèle :
> 
> <!ELEMENT documentBase (systemMetadataRepository, searchIndexRepository, 
> repositories+)>

Pour unifier la terminologie, je vais utiliser le terme "Repository" qui 
indique bien que l'on stocke de la donnée. Je reprends donc mon raisonnement :

1) La DocumentBase devrait être *totalement* indépendante des repositories. 
Elle ne ferait que les instancier et d'appeler leurs méthodes lors des INSERT, 
UPDATE, DELETE des documents.
2) Toute DocumentBase possèderait un et un seul MetadataRepository qui 
stockerait :
- l'id du document
- le repository dans lequel il se trouve
- toute autre information utile (timestamps)

Objectif : obtenir une référence unique à un document. La centralisation dans 
la base de documents est donc forcément nécessaire.

3) Toute DocumentBase possèderait un et un seul SearchIndexRepository qui 
stockerait les valeurs indexées. Pour l'instant, ce SearchIndexRepository ne 
serait implémenté que sur Lucene. La centralisation dans la base de documents 
est également nécessaire.
4) Toute DocumentBase possèderait (et possède déjà !) au moins un 
(Document)Repository.

L'architecture actuelle de (Document)Repository est excellente. A ce stade 
précoce de SDX, on a déjà des FSRepository, URLRepository, JDBCRepository 
dérivés de AbstractRepository et implémentant Repository.

Je veux obtenir la même chose pour les Repository "système", même si, pour 
l'instant, seule l'architecture Lucene peut être proposée. Il faudrait donc 
proposer :

a) des interfaces pour ces repositories spécifiques
b) des classes abstraites à partir desquelles on pourrait dans un premier temps 
sous-classer des LuceneXXXRepository.

Bref, faire la même chose que ce qui a été fait pour les (Document)Repository !

Autre chose qu'il pourrait être intéressant de passer dans une classe : le 
document XML resultant de la XSLT d'indexation. J'aimerais pouvoir y accéder, 
via DOM probablement...

Je donne la code actuel (nanti de mes commentaires en attente de commit) de la 
stratégique méthode LuceneDocumentBase.add(IndexableDocument doc, Repository 
repository, RepositoryConnection conn). Notons en passant que c'est une méthode 
*privée*, ce qui est le niveau maximal d'encapsulation.

On a d'abord :

   //Prepare a Lucene "document"
   org.apache.lucene.document.Document lDoc = new 
org.apache.lucene.document.Document();
   
   //Feed Lucene "fields" with the document's index values 
   Enumeration fieldVals = doc.getFieldValues();
   while (fieldVals != null && fieldVals.hasMoreElements()) {
    Property prop = (Property) fieldVals.nextElement();
    //TODO: what do we do with non defined fields??? For now we will have a 
NPE...maybe just index and tokenize no store!
    Field f = 
fieldsDef.getField(prop.getName()).getLuceneField(prop.getValue());
    lDoc.add(f);
   }
   
   //Set fixed names Lucene "fields"
   //TODO : did we previously get sure that these "fields" were actually 
reserved names ? -pb
   Field fId = Field.Keyword("sdxdocid", doc.getUniqueId());
   lDoc.add(fId);
   Field fId2 = Field.Keyword("sdxall", "1");
   lDoc.add(fId2);
   
   //Lucene "document" is now ready

Ce code pourrait être confié à une méthode 
LuceneIndexationDocumentHandler.Generate(doc) (ouf !). Je pense d'ailleurs 
reparler de ce handler...

Ensuite, on stocke l'indexe de recherche (on est encore dans l'ancien 
ordonnancement) :
   
   //Step 1 : Write this Lucene "document" into the Lucene search index
   writeIndex(ACTION_ADD_DOCUMENT, lDoc);
   //TODO: uncomment the below line once we are able to make changes to 
lucene's code
   //writeIndex(ACTION_ADD_DOCUMENT, lDoc, field.getAnalyzer())

Je demande donc que cette méthode WriteIndex (privée également) soit dans une 
classe SearchIndexRepository ou plutôt, au vu du code précédent, dans un 
LuceneSearchIndexRepository, classe concrète issue de la première qui, elle, 
serait abstraite.
   
   //Step 2 : write this document into the repository
   //TODO : well, I think it would be a step 1 process. 
   //It doesn't make sense to me to save search info if the document could not 
be saved before ! -pb
   if (repository == null) {
    //No repository given : get the default one...
    repository = defaultRepository;
    //but we'll have to manage the connection ourselves !    
    conn = repository.getConnection(); //TODO : throw an warning/error if a 
connection was given ? -pb
    repository.add(doc, conn);
    repository.releaseConnection(conn);
   }
   else if (conn == null) {
    //No connection given : we'll have to manage the connection ourselves
    conn = repository.getConnection();
    repository.add(doc, conn);
    repository.releaseConnection(conn);
   }
   
   //If a repository and a connection were provided, we leave the connection 
management up to the method which made the call
   else repository.add(doc, conn);

Rien à toucher ici. C'est OK car *independant* de toute architecture. Que l'on 
soit sous un FSRepository, un URLRepository ou un JDBCRepository ou que l'on 
redirige vers le périphérique nul, la DocumentBase n'y voit que du feu !
   
   //Step 3 : save the document reference into the document base's index 
(sdxRepoIndexDB)
   //TODO : well, I think it would be a step 2 process. 
   //It doesn't make sense to me to save index info if the reference to the 
document could not be saved ! -pb
   
   //Create a reference to the document
   DatabaseEntity dbe2 = new DatabaseEntity(doc.getUniqueId());
   dbe2.setLogger(this.logger);
   dbe2.enableLogging(this.newLogger);
   //Containing the repoId...
   dbe2.addProperty(REPO_PROPERTY, repository.getId()); //TODO : add other 
properties ? -pb
   //These could include doc.getId() - not unique -, creation timestanmp, 
indexation timestamp, user info, etc.
   //I think it would be worth the value to create a special dedicated class 
(maybe an inner one) for this
   
   //Save the reference to the document
   sdxRepoIndexDB.save(dbe2);

Ici encore, on pourrait déléger à un MetadataRepository ou, plus exactement 
ici, dans un LuceneMetadataRepository...

Voilà. Bien sûr, Delete (unIndex) est bâtie strictement sur le même modèle.

p.b.




















> 
> L'avantage serait :
> - de ramener la classe DocumentBase à une classe indépendante des 
> architectures sous-jacentes. Plus besoin d'interface ni de classe abstraite...
> - de pouvoir disposer d'un système d'évènements bien plus fin. En l'état 
> actuel des choses, il m'est très difficile de transmettre à un gestionnaire 
> d'évènements le XML résultant de la XSL d'indexation.
> - de permettre, pour ceux que ça intéresserait, de stocker différentes choses 
> sur différentes architectures.
> 
> Note : dans un premier temps, une architecture Lucene serait selon moi 
> suffisante !
> 
> Pour être plus démonstratif :
> 
> au lieu de :
> 
> <sdx:documentBase id="apps" type="lucene" default="true">
>   <sdx:repositories>
> ... rien à changer ici ; c'est *très bien *
>   </sdx:repositories>
> </sdx:documentBase>
> 
> j'aimerais :
> 
> <sdx:documentBase id="apps" default="true">
>   <sdx:systemMetadataRepository type="jdbc"/>
>   <sdx:searchIndexRepository type="lucene"/>
>   <sdx:repositories>
> ... rien à changer ici ; c'est *très bien *
>   </sdx:repositories>
> </sdx:documentBase>
> 
> 
> > Si tu veux stocker des métadonnées en MySQL, alors tu développes
> > une classe MySQLDatabase qui implante Database. Ensuite on permet de
> > configurer (dans app.xconf) quel type de gestionnaire de métadonnées
> > utiliser. Ce n'est pas suffisant?
> 
> Euh... c'est le repository qui serait sous MySQL et, effectivement, il y a 
> une classe pour ça qui m'a l'air d'être au point. Les métadonnées, j'aimerai 
> effectivement les mettre sous MySQL qui sait en principe convenablement les 
> gérer. En revanche, pour l'index de recherche, Lucene reste pour l'instant le 
> meilleur.
> 
> >Je ne sais pas si tu veux unifier la recherche documentaire effectuée
> >avec Lucene avec la gestion de métadonnées gérée par l'interface
> >Database, mais pour moi ça ne devrait pas.
> 
> Non, non. Sois sans crainte à ce sujet.
> 
> > SDX est un outil de recherche, et la DocumentBase est justement ce lieu
> > qui est cherchable. Pour l'instant, le seul moteur de recherche est
> > Lucene, mais éventuellement il y en aura d'autres. D'où l'idée de
> > l'interface et de la classe abstraite.
> 
> J'ai bien compris, mais telle que cette classe est foutue, toute nouvelle 
> classe nécessitera pas mal de codage car cette classe a à gérer non seulement 
> la délégation aux repositories (ce qui est simple) mais également la création 
> du document d'indexation, son mapping sur une architecture et la gestion des 
> métadonnées sytème. Pour faire court, là où il y a une seule classe, j'en 
> voudrais 3 (voire 4 si l'on considère que génération du document XML 
> d'indexation et mapping du searchIndex sont deux choses différentes). Que 
> cela ne fasse pas peur : tout ce code existe déjà !
> 
> > Par exemple, il sera assez facile d'ajouter une classe XMLDBDocumentBase
> > qui fera des recherches Xpath dans un entrepôt de type XMLDB. Un jour
> > qu'il y aura un bon moteur XMLQuery, on l'implante, etc. Et SDX peut
> > donc intégrer différents moteurs de recherche, l'élément commun étant
> > justement cette interface DocumentBase.
> 
> J'ai bien saisi et je suis effectivement persuadé que de sotcker le XML 
> d'indexation *en natif* (d'où l'idée de 4 classes) devrait apporter de la 
> performance. J'attends avec impatience le match contre Lucene !
> 
> > L'architecture actuelle est justement prévue pour cela. Je ne comprends
> > pas ce qui manque (à part des trucs à implanter).
> 
> J'espère avoir été clair. Si ce n'est pas le cas, je vous derai un 
> éventuellement un dessin montrant une classe DocumentBase délégant à 3 types 
> de repositories pouvant les uns et les autres s'appuyer sur des architectures 
> différentes...
> 
> p.b.
> 
> 
> ±z¢²--±z¢².z·y¢¸!¶Úþf¢.úÞzÊ·«yû¢¸?T¨¥T©ÿ-+-SwèþÇquëÞ-S^