Re: RE : [sdx-developers] RE : documentbase

[Pierrick Brihaye]

Martin Sévigny wrote:

> > 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. 
>
> Parce qu'il n'y a pas d'autre implantation actuelle pour les
> métadonnées...


Je l'ai bien vu (et ce 'nest pas un reproche). Le mot important était le 
"et".

Plaçons nous à long terme : on a N moyens de faire persister des 
informations : Lucene, JDBC, XML-DB et que sais-je encore.

Le package repository prévoit cette diversité, même s'il ne prévoit que 
(!) 3 moteurs et quart : FS, URL, JDBC, MySQL.

Le package documentbase gère cette diversité de façon moins habile à mon 
avis : on a, hormis les documents, à stocker les références et l'index 
de recherche. Là, c'est fromage et dessert : dans une 
LuceneDocumentBase, on stocke les références (via 
utils.database/LuceneDatabase) *et* l'index sous Lucene. Si on avait une 
XMLDBDocumentBase, on stockerait les références  *et* l'index sous 
XML-DB... Si un bonhomme vient en disant "je veux stocker mes références 
sous MySQL et mon index de recherche sous Lucene", on fait quoi ? Une 
MySQLLuceneDocumentBase ? A moins que ce ne soit une 
LuceneMySQLDocumentBase ? Tant que la combinatoire est de 1, une seule 
classe suffit. Si elle parvient à 2, 2 classes suffisent, mais après, on 
est en progression géométrique.

Ce que je voudrais, c'est un ReferenceRepository et un 
SearchIndexRepository. Dans un premier temps, les 2 seraient sous 
Lucene, CE QUI NE ME GENE PAS (et qui n'est qu'un amènagement de la 
combinatoire actuellement disponible). Ce qui me gêne, c'est 
l'encapsulation forte dans LuceneDocumentBase, et qui m'empêche 
d'accéder au document d'indexation.


> ... C'est exactement ce qui est prévu. Le nom "LuceneDocumentBase" vient
> qualifier le type d'engin de recherche (Lucene), pas le type d'engin de
> métadonnées.


Euh... j'ai du louper quelque chose. Car, dans ce que j'ai vu, les 
métadonnées (les références) sont également stockées avec Lucene (via 
les DatabaseEntity). Quand bien même, si je lance index() qui lance 
add() (private) qui lance writeIndex() (private aussi), je ne peux pas 
accéder de façon facile à mon document, surtout si j'utilise le add qui 
prend un tableau en paramètre...


> C'est pourquoi la définition d'une base de documents de type Lucene
> comporte des champs, alors que la définition d'une base de documents de
> type XMLDB comporterait des index définis par des Xpath, ces index étant
> (comme en SQL) une façon d'accélérer les recherches, rien de plus.


Je ne dis pas le contraire : dans le schéma que j'ai proposé, mon 
"searchIndexRepository" a un type donné : Lucene, JDBC ou tout ce qu'on 
voudra. Et comme il est de cardinalité 1, le concepteur d'application 
sait exactement à quoi s'attendre. S'il met un searchIndex en "Lucene", 
il sait qu'il pourra avoir des FieldQuery, des WildcardsQuery... S'il 
veut du X-Path, il n'aurait qu'à mettre son searchIndex en "XMLDB" (mais 
voir plus bas) et utiliser X-Path.

BTW. On pourrait ainsi concevoir un build.xml qui prendrait des 
paramètres comme -withmysql, -withlucene, withxmldb, 
-witheverypersistencymanagerthatcouldbehandledbysdx. Ainsi, moins de 
débats sur le core et l'optional :-)


> Je ne vois pas comment une même classe pourrait gérer à la fois des
> index de recherche de type Lucene et des bases XMLDB.


Elle n'aurait pas à les gérer. Elle n'aurait qu'à déléger. Elle donne le 
XML d'indexation au manager qui se débrouille avec : Lucene mappe ça sur 
des LuceneDocument et analyse, XMLDB mappe ça sur du XML et n'analyse 
pas ;-)... ou repasse une XSL dessus pour "analyse complémentaire" :-)). 
Même chose à la requête : si le concepteur d'application envoie une 
TermQuery à un SearIndexRepository sous XMLDB, c'est qu'il s'est planté 
("SearchManager did not understand the query"). Dans tous les cas, 
l'important est que les managers renvoient des sdx:results propres.

> MySQL sait correctement les gérer... Mais attention aux occurrences
> multiples ;-)


Je viens d'en parler dans un autre post ;-))


> Oui, mais si je reprends mon scénario de base de documents XMLDB, on n'a
> pas besoin de transformation d'indexation, tu vois?


On pourrait encore en discuter. Pour ceux que ça amuse, ils pourraient 
reparser le XML d'indexation. Ca pourrait aider pour les thesauri par 
exemple : le document stocke "cathédrale", l'index stocke "édifice 
religieux chrétien"... Mais bon, je suis d'accord. A priori, l'intérêt 
est limité...

> Alors je pense que
> oui ce code est spécifique à une base de documents Lucene, ou plutôt à
> une base de documents où l'utilisation de la structure se fait a priori.


C'est le SearchIndexRepository qui se définit a priori. Tout le reste a 
un niveau d'abstraction suffisamment fort pour être mappé sur n'importe 
quoi (tant qu'on reste en monovaleur). Encore une fois, je répète que le 
package repository en est une preuve éclatante !

> Ah! Tu pense que de stocker le XML d'indexation en XMLDB apportera
> quelque chose?


A vrai dire... non :-)) Ceci dit, j'aimerais bien tener une indexation 
Lucene mappée sur un SGBD et ce pour une raison : le rollback. Si 
j'avais ça, je ferais un peu plus de SDX 2 et de carto plutôt que de me 
retrouver, à 17h25, avec 525 documents dans ma base :-)

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