Re: [sdx-developers] Commits du jour

[Pierrick Brihaye]

Salut,

Lorenzo Arcaini a écrit :

> Ca vient en conséquence de la gestion de l'optimisation des index. En 
> fait ce qui était présent avant en mémoire dans le RAMDirectory devient 
> un FSDirectory et correspond au répertoire "current".

> A chaque index son répertoire donc. Le fait que le RAMDirectory soit
> passé en FSDirectory vient d'un problème de perte des données qui
> pouvait survenir tant que l'index n'était pas optimisé. En effet, sans
> optimisation les informations du RAMDirectory pouvaient êtres perdus en
> cas de fermeture intempestive de SDX. Comme l'optimisation était
> systématique avec SDX 2.2 le problème ne se posait donc pas.

OK. pas de problème sur ce choix.

> Tandis que ce qui était l'index contenu dans /sdx-search-index/ sous SDX 
> 2.2 a été déplacé dans le répertoire "main".
>
> En terme de structure ça nous donne ceci :
> /sdx-search-index/current/
> /sdx-search-index/main/
> auquel il faut ajouter tous les sous index possibles issus du "split"
> /sdx-search-index/0000/
> /sdx-search-index/0001/
> ...

C'est ici que j'ai du mal à comprendre : en quoi "0000" est-il moins 
"main" que "main" ? :-)

Quant à "current", est-ce qu'un nom "temp", "to_be_merged" ou quelque 
chose comme ça ne serait pas plus signifiant ?

Autant "current" me semble un nom valable dans des conditions normales, 
autant ça me paraît plus bizarre lorsqu'on redémarre SDX après le crash 
que tu as évoqué.

Ca n'entâche en rien les fonctionnalités cependant.

Autre chose sur ce point, sans doute plus coton. Plutôt que de balancer 
toute la logique dans ce pauvre package 
fr.fouv.culture.sdx.documentbase, ne serait-il pas plus opportun de de 
confier cette gestion d'index à un truc du genre 
fr.gouv.culture.sdx.search.lucene.SmartLuceneIndicesManager ?

Mes 2 centimes...

A+

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden
+33 (0)2 99 29 67 78