sdx-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sdx-developers] M�tadonn�es syst�mes


From: Pierrick Brihaye
Subject: Re: [sdx-developers] Métadonnées systčmes
Date: Tue, 11 Jun 2002 19:26:31 +0200

Je m'étonnais de l'absence de réponse. Je suis allé voir dans les archives (je 
suis chez moi) pour voir qu'il y avait bien réponse, et je réponds après un 
copier/coller...

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

> Mais non, je me tue à le répéter, c'est faux (ou plutôt temporaire). 

Aaaah. Je crois qu'on va s'entendre :-) On est donc d'accord que la gestion des 
références sont *temporairement* codées en dur ?

>Un
>LuceneDocumentBase, par _définition_, fait la recherche avec Lucene. Son
>système de gestion interne est un Database dont le type (Lucene, MySQL,
>etc.) sera configurable.

Eh bien oui, on est d'accord.

Passons maintenant Ă  la DocumentBase (titre du thread) :

On a :

LuceneDocumentBase (spécifique Lucene)
- Repository (générique : délègue à des repository spécifiques)
- ReferencesManager (spécifique : encapsulé temporairement ; à revoir pour 
qu'il devienne générique et qu'il délègue à des repositories spécifiques)
- SearchIndexManager (spécifique Lucene : encapsulé à fond)

Intellectuellement, je trouve bizarre que l'on ait un haut niveau spécifique à 
cause *d'un seul* sous-élément qui l'est... Un père qui hérite de son enfant, 
quoi... Je proposais donc une couche d'abstraction sur le SearchIndex de façon 
à regénériciser son père, *étant entendu* qu'il y aurait une forte variabilité 
dans les comportements d'indexation selon les plate-formes sous-jacentes. A 
charge pour les SearchIndexManagers de les gérer. Une DocumentBase générique 
n'aurait eu qu'à transmettre la Query et à fournir un objet chargé de recevoir 
les réusltats ou... une exception.

> On fait <sdx:documentBase type="Lucene" metadata="MySQL"> ou quelque
> chose du genre.

Soit.

>Ben voilà! D'où l'interface DocumentBase, pour déléguer! Ce qui
>obscurcit la chose, c'est que tout ou presque est codé en dur à ce
>sujet, mais ça changera.

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

Pas facile pour le moment parce que l'appel à index ne va pas forcément générer 
un add (comportement de mise à jour défini dans les paramètres d'indexation), 
mais bon, c'est normal. Cela m'obligera à passer des paramètres pour signaler 
les choix de stratégies faits par la DocumentBase aux gestionnaires 
d'évènements.

Plus gênant encore dans ma problématique actuelle, comment je fais pour accéder 
au XML d'indexation ? J'ai bien IndexableDocument.GetFieldValues mais... c'est 
très typé Lucene ce truc là :-) N'aurions nous pas plutôt là un 
LuceneIndexableDocument ? Personnellement, je trouverais intéressant de tout 
ramener en XML.

Prenons un cas d'indexation Lucene, oĂą l'on travaille Ă  partir de :

<sdx:document id="machin">
  <sdx:field name="un_mot">des mots par dizaines</sdx:field>
  <sdx:field name="une_valeur">bla</sdx:field>
</sdx:document>

En fait, Lucene, qui est multichamps (plutôt que multivaleurs) va générer un 
LuceneDocument qui, en pseudo-XML, donnerait après analyse ultra-basique :

<sdx:document>
  <sdx:field name="id">machin</sdx:field>
  <sdx:field name="un_mot">des</sdx:field>
  <sdx:field name="un_mot">mots</sdx:field>
  <sdx:field name="un_mot">par</sdx:field>
  <sdx:field name="un_mot">dizaines</sdx:field>
  <sdx:field name="une_valeur">bla</sdx:field>
</sdx:document>

Moralité : XML peut-être partout :-)

Idem pour les métadonnées système :
<sdx:document>
  <sdx:field name="id">une id</sdx:field>
  <sdx:field name="repository">un repository</sdx:field>
  <sdx:field name="date_created">a date</sdx:field>
  <sdx:field name="date_modified">a date</sdx:field>
  <sdx:field name="date_indexed">a date</sdx:field>
...
</sdx:document>

Partant de lĂ , je voudrais pouvoir disposer d'une interface sur Document (car 
même les documents attachés peuvent avoir ne serait-ce que des données système) 
me permettant d'accéder à une vue XML de ces métadonnées 
Document.GetIndexation(), Document.GetSystemMetadata.  Que ça me renvoie du 
DOM, du SAX, du flux ou autre chose ne me dérange pas. Bien sûr, les 
systemMetadata étant par définition définies par le système, l'objet retourné 
devrait être en lecture seule... mais pas le précieux document d'indexation que 
je m'empresserai de modifier dans mon beforeIndexAdd :-)

Pour finir sur la v. 1 :

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

>Dans ce cas il faut contribuer au projet Lucene, pas au projet SDX! ;-) 

Mmmh. Le problème est-il dans Lucene ? J'ai plusieurs soupçons : 
- ressources système sur mon serveur Linux
- problèmes dans la blackdown
- SDX ! GetIndexReader, deleteIndexedDocument, getWriter, releaseWriter ne sont 
pas synchronisées. Ne sachant pas vraiment si c'est critique dans le cas d'une 
réindexation, surtout avec des accès concurrentiels, je me demande s'il n'y a 
pas là un problème.

p.b.

Attachment: IndexableDocument.java
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]