search

geobretagne / mdchecker

This is a simple quality assurance tool performing unit tests on a CSW-enabled catalog.
GNU General Public License v3.0
2 stars 2 forks source link

Coupler une base de données #5

Closed bchartier closed 8 years ago

bchartier commented 8 years ago

Je me pose la question de faire évoluer mdchecker pour y coupler une base de données. L'idée serait d'y stocker les résultats des tests afin de pouvoir faire des statistiques et de les présenter. Bonne ou mauvaise idée ?

fphg commented 8 years ago

Si base de données, elle doit historiser pour témoigner d'une évolution. Le graphe qui m'intéresserait beaucoup serait f(producteur, temps, qualité). Il faudrait stocker systématiquement (datetime, id_md, qualité), ce qui permettrait d'une part d'afficher une progression unitaire par md (réutilisable sur les synthèses de page), d'autre part de reconstituer des vues producteur (par exemple)

bchartier commented 8 years ago

Parfait. Pour le moteur de base de données, j'envisage plutôt une base de données qui ne nécessite pas de déploiement ni d'administration et manipulable facilement avec du Python : SQLite. Un truc NoSQL pourrait peut-être faire l'affaire mais je ne vois rien de comparable à SQLite. Une idée ? Une opinion ?

fphg commented 8 years ago

Le 05/08/2016 09:54, Benjamin C. a écrit :

Parfait. Pour le moteur de base de données, j'envisage plutôt une base de données qui ne nécessite pas de déploiement ni d'administration et manipulable facilement avec du Python : SQLite.

Oui pourquoi pas. Inconvénient, cela ne facilite pas la réutilisation par un dispositif présent sur une autre machine. Je pense surtout que le stockage doit être optionnel.

Un truc NoSQL pourrait peut-être faire l'affaire mais je ne vois rien de comparable à SQLite. Une idée ? Une opinion ?

Pour une seule table...

Ceci dit, je n'aurai pas d'état d'âme à stocker les résultats dans la base georchestra, en bénéficiant en sus de l'authentification.

bchartier commented 8 years ago

Je pense surtout que le stockage doit être optionnel.

optionnel à quel moment : au moment du déploiement ou au moment de l'exécution ?

Pour une seule table...

Bah, je ne serais pas étonné qu'on arrive à 2 tables, puis à 3...

Ceci dit, je n'aurai pas d'état d'âme à stocker les résultats dans la base georchestra, en bénéficiant en sus de l'authentification.

Visiblement les modules Python clients de SQLite et PostgreSQL implémentent DBAPI. L'accès à une base SQLite ou PostrgeSQL de geOrchestra devrait se configurer en douceur. Je vais regarder si SQLAlchemy serait une bonne idée ou pas pour assurer un maximum d'interopérabilité.

bchartier commented 8 years ago

J'ai fait une première ébauche d'intégration d'une base de données. Je l'ai mise sur la branche with_db du repository de Neogeo pour l'instant : https://github.com/neogeo-technologies/mdchecker/tree/with_db Une fois que ce sera plus mûr, je la basculerai sur le dépôt GéoBretagne.

Ceci dit, je n'aurai pas d'état d'âme à stocker les résultats dans la base georchestra, en bénéficiant en sus de l'authentification.

Visiblement les modules Python clients de SQLite et PostgreSQL implémentent DBAPI. L'accès à une base SQLite ou PostrgeSQL de geOrchestra devrait se configurer en douceur. Je vais regarder si SQLAlchemy serait une bonne idée ou pas pour assurer un maximum d'interopérabilité.

J'ai utilisé SQLite et SQLAlchemy. Configurer l'appli pour PostrgeSQL semble aisé.

Pour une seule table...

Bah, je ne serais pas étonné qu'on arrive à 2 tables, puis à 3...

Effectivement, j'ai créé 4 tables

Je pense surtout que le stockage doit être optionnel.

Pour l'instant, le stockage n'est pas optionnel. Il ne manque peut-être pas grand chose pour le rendre optionnel.

@fphg : n'hésite pas à me faire un retour si jamais tu as le temps d'y jeter un œil.

bchartier commented 8 years ago

je ferme, la base est là et c'est opérationnel (à part #10)