Re: [sdx-developers] documentbase

[Pierrick Brihaye]

Salut,

Frédéric Glorieux wrote:

>     Bien que je ne puisse y contribuer,


Ah bon ???

> je voulais d'abord souligner
> l'intérêt formateur de vos discussions sur le partage conceptuel des métodes
> entres bases et dépôts.


Merci (en tout cas en ce qui me concerne). Comme souvent toutefois, mes 
interventions sont basées sur l'expérience. Dans mon cas, je veux 
pouvoir ajouter des champs d'indexation supplémentaires que je ne peux 
pas générer dans ma XSLT d'indexation (sauf à disposer d'extensions, ce 
qui me gêne assez car ça m'obligerait à exécuter du code en dehors du 
contexte SDX, sans compter les problèmes de normalisation). Ceci dit, je 
reconnais bien volontiers que l'expérience reste encore la meilleure 
base de la formation (c'est un enseignant occasionnel qui vous le dit ;-))).

> De plus, je souhaitais attirer l'attention sur une
> remarque de Pierrick à propos de l'arborescence "conf" d'une application,
> qui pour un auteur d'application, permet de plus facilement concrétiser vos
> conclusions.
>
> << A ce propos, dans l'appli sdxworld, j'ai :
> sdx
> - sdxworld
> -- conf
> --- dbs
> ---- apps
> ----- documents
> ------_lucene
> ------- doc
> ----- sdx-repo-index
> ----- sdx-search-index
> --- users
> -- css
> -- documents
> -- xsl
>
>     Si je crois comprendre, à chaque base correspond un "sdx-search-index" -


Je crois qu'on a compris la même chose :-)


> OK. On pourrait brancher un index mysql (j'ai cru en voir tourner un en
> PHP),


Par exemple, mais, honnêtement, ça me parait difficile. Comme on est en 
multivaleur, il faut soit avoir autant d'enregistrements que d'entrées 
(avec une combinatoire qui risque vite de devenir abominable), soit 
déporter dans d'autres tables (et, effectivement, il y a peut-être des 
librairies qui savent faire ça). Malheureusement, comme MySQL n'accepte 
actuellement les foreign keys que sur le papier... Ceci dit, sur 
d'autres SGBD et, surtout, sur un SGBD XML, ça devrait pouvoir le faire. 
On en reparle tout de suite...

> par contre, je vois mal ce que contiendrais ce répertoire en cas de
> recherche Xpath (ou Xquery).


Oui. Selon moi, une requête de ce type concernerait le document 
lui-même, pas ses index. Mais c'est à discuter. Et le fait même que ce 
soit à discuter prouve bien qu'il faut génériciser l'accès aux index de 
recherche ;-) COMME CELA A ETE FAIT POUR LES REPOSITORYs.


>     On trouve aussi un "sdx-repo-index". Je le suppose utile pour une
> correspondance "sdxdocid-repository" auquel je rattache cette remarque de
> Pierrick


Même problématique. Quoique dans ce cas, on est probablement monovaleur 
(sauf si on fait du versionning : on en reparlera pour SDX 3). Dans ce 
cas, MySQL pourrait effectivement aider...


>     L'utilisateur pourra-t-il avoir accès à ces champs ? Pourrait-il s'en
> définir pour lui ? Pour une application édition/diffusion, les méta-données
> (last-user, log des modifs ...) n'ont logiquement pas grand chose à voir
> avec l'indexation du document lui-même. J'ai peur de poursuivre dans ce
> sens, car il me faudrait alors de l'info de config comme pour
> <sdx:userDocumentBase/>... mais évitant l'inflation, votre sagacité saura
> arrêter une solution.


J'ai parlé de métadonnées "système" qui, a priori, ne seraient utilisées 
que par le système pour ses tâches internes (réparation, 
réindexation...). Toute autre métadonnée devrait, elle, accompagner le 
document dans son repository. Mais bon, on peut aussi concevoir des 
métadonnées utilisateur... Là encore, si la classe DocumentBase est bien 
foutue, c'est une ligne de plus dans index() et une ligne de plus dans 
delete() : i.e. UserMatadataRepository.add(document.getUserMetadata()) 
et UserMatadataRepository.delete(document) !


>     Dans le dépôt fichier, on trouve encore un index Lucene, je le suppose
> nécessaire pour le rendre aussi intelligent qu'un SQL ou Lucene. On a a déjà
> beaucoup parlé, ce "FSR" risque de décevoir l'utilisateur qui espérait un
> bidule ou on met ses fichiers à la main comme on veut,


Euh... là  je commence à être paumé ! Ce n'est pas un URLRepository ? 
C'est que moi, je veux effectivement mettre me fichiers à la main ! Par 
des liens symboliques, mais peu importe.

> et puis sdx s'occupe
> de réindexer dès que ça change.


Nous sommes d'accord :-))) Rhaaa... ça fait du bien !

> Aussi je me pose 2 questions
>     Ne vaudrait-il pas mieux un "repository" Lucene par défaut ?


Eh, eh...

> (Les
> fichiers attachés seraient supportés lorsque Lucene stockera du binaire).
>     Un dépôt URL aura-t-il des robots d'exploration par défaut (HTML:<a
> href=""/>, XML:<xlink/>, file://:*.xml), et des robots de mise-à-jour (ex:
> check links each day and index if changes) ?


Oh, oh :-)

Bon, je reviens sur le problème des données accompagnant un document. On 
a donc :

- des métadonnées système : id, repository, timestamps divers...
- d'éventuelles métadonnées utilisateur qui, elles, seraient définies 
pour chaque DocumentBase dans un fichier de config. Pas urgent pour le 
moent...
- des données d'indexation, résultant d'une transformation XSL. 
J'insiste sur ce point, SDX se voulant être un système tout XML.

Il me semble que le format pivot est donc le XML. Le document est 
formalisé en XML, les métadonnées peuvent être formalisées en XML, les 
données d'indexation peuvent être formulées en XML. En conséquence, 
plutôt que document.getFieldValues(), qui renvoie un truc propre à 
Lucene, on devrait avoir 
LuceneSearchIndexRepository.fromXML((document.GetSearchIndexValuesAsXML)) 
(ouf !). Bref, mapper sur la structure propriétaire le plus tard possible...

Gros intérêt : on peut très facilement mapper sur une BD XML, voire sur 
un SGBD disposant de filtres de type XML2SQL.

Ce dernier point me paraît moins prioritaire car, je le répète, on peut 
ne proposer dans un premier temps que des searchIndex de type Lucene.

A+

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