Re: [sdx-developers] HSQLDatabase

[Pierrick Brihaye]

Salut,

Commentaire sur les commentaires :-)

Pierrick Brihaye a écrit:

> Malgré un plan de nommage que
> je trouve discutable (en particulier l'arborescence
> fr.gouv.culture.sdx.utils)

Je veux dire par là que :

1) est-ce qu'il ne vaut pas le coup de créer un package "lookups" ?
2) On a utils/database, utils/lucene, utils/rdbms. N'est-il pas plus 
opportun d'avoir utils/database/lucene, utils/database/rdbms ? Surtout 
qu'on a utils/rdbms/hsql...
3) Je ne trouve pas DataSourceComponentBacked très explicite. Et JDBC 
est carrément trompeur IMHO.

Rien d'important à vrai dire ; ça peut attendre une réflexion plus 
approfondie : voir éléments ci-après :-)

Voilà :

La DatabaseEntity correspond à ce que j'ai appelé un objet à 2,5 
dimensions. Les lookups, avec la possibilité de les multivaluer, sont 
effectivement des objets de ce type.... mais aussi les "documents 
d'indexation" !

Dans ces conditions, on pourrait aussi stocker les index "Lucene-like" 
dans des BD. Bien sûr, il faudrait cabler les requêtes, les résultats et 
tout le toutim. Brrrr !

L'objet Property (et non DatabasePorperty comme on aurait pu s'y 
attendre) a un comportement que j'appellerais "optimiste". En effet, il 
ignore volontairement l'accès à des valeurs inexistantes (getValue, 
suppression...). De plus, la méthode setValues est en fait une 
méthode... addValues (l'ArrayList n'est pas purgé avant). A vrai dire, 
ça n'a gêné personne jusqu'à maintenant, mais sera-ce encore le cas si 
on a un index SGDB unique sur les triplets id/Name/Value ???

J'ai un problème d'approche conceptuelle pour lequel je n'ai pas d'idée 
bien arrêtée : il concerne les relations.

Petit rappel :

- les documents sont stockés dans des repository
- leurs "métadonnées" sont stockés dans des lookups. La discussion est 
ouverte quand à savoir à quel niveau stocker ces lookups. Voir arguments 
présentés dans les messages précédents. A signaler que pour les 
JDBCRepository, on a une architecture *imposée* :-(
- Les index sont stockés dans une architecture dédiée.

Tout ça est clair et à peu près cohérent ; ça devrait le devenir encore 
plus une fois que les décisions ad hoc seront prises... Bien :-)

Par contre, j'ai encore du mal à saisir à quel niveau doivent être 
stockées les relations. Pour l'instant, elle le sont dans les lookups, 
ce qui, même si on dispose du choix de leur architecture, ne me paraît 
pas être la panacée.

En effet :

Les relations ne sont pas dépendantes des repositories (v. messages 
précédents sur les documents attachés stockés dans des repositories 
différents de celui où est stocké le document "maître").

Les relations ne sont en aucun cas dépendantes des index (rappel inutile 
mais pratique pour raisonner par élimination :-).

Reste 2 solutions : la base ou l'appli.

En l'état actuel des choses, l'appli risque d'être très compliquée à 
gérer (parce qu'on peut y avoir des bases distantes).

Reste donc une seule solution, de bon sens qui plus est : la base.

A partir de là, 2 solutions (ou plus ?) :

- conserver l'architecture actuelle est stocker les lookups/relations au 
niveau de la base. J'aime pas pour les raisons expliquées auparavant :-(
- revoir l'architecture pour stocker les relations dans des lookups qui 
seraient *nécessairement* au niveau de l'appli.

J'aime bien cette deuxième solution mais elle est incompatible avec 
l'architecture existante. Elle permettrrait cependant d'offrir à SDX un 
sysème de résolution de liens très puissant : j'y réfléchis encore...

A+

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