Accès public à la base SQLite legi.py

[Seb35]

Je trouve qu’il serait judicieux de donner un accès public à la base SQLite mise à jour quotidiennement afin que les gens qui ne font pas tourner legi.py quotidiennement aient accès aux données. (À ma connaissance, il n’y a que 2 déploiements mis à jour quotidiennement, ceux de anomalies.legilibre.fr et archeo-lex.fr).

Dans l’idée, ça serait un portail un peu comme https://query.wikidata.org qui donne accès aux données de Wikidata moyennant le fait qu’il faut connaître SPARQL. Afin d’atteindre rapidement cet objectif à peu de frais, il y a des logiciels comme PHPLiteAdmin et quelques autres qui s’appelle un peu pareils (Wikipédia a même un article même si deux tels logiciels sont inactifs).

J’ai un peu testé celui actif, PHPLiteAdmin : il est rudimentaire mais fait le job. De toutes façons, il faut être un peu technicien et connaître le SQL, donc ce type de public saura globalement se débrouiller même si l’interface n’est pas des plus abouties.

Qu’en dites-vous ? @Changaco @fgallaire
Je peux m’occuper de ce déploiement, et faire en sorte que les données ne soient pas modifiables via le web. Aussi, il faudrait trouver un nom de sous-domaine : sqlite.legilibre.fr ?

[Changaco]

J'avais déjà envisagé cela, mais les interfaces web existantes que j'avais pu trouver (notamment sqlite-web) sont conçues pour l'administration des bases de données, pas pour faciliter l'exploration d'une base publique.

Empêcher toute modification des données est techniquement plutôt simple, il suffit que le processus web n'ait accès au fichier SQLite qu'en lecture et pas en écriture. Par contre empêcher qu'un visiteur ne puisse surcharger le serveur avec des requêtes complexes est beaucoup moins évident.

[fenollp]

SQLite est pas fait pour être utilisé à travers un WAN. Est-ce que fournir une tarball peut être dans les release de github ou sur un site statique gratuit ne serait pas plus simple ?

[Changaco]

@fenollp L'intérêt d'un accès public comme proposé par @Seb35 est de ne pas avoir à télécharger et stocker toute la base soi-même. Le fichier SQLite contenant la base LEGI fait actuellement + de 3Go.

[revolunet]

Hello !

Je pense aussi qu'il serait judicieux de mettre à disposition une version à jour de la base. A minima sous forme de download http.

Une autre approche serait de "convertir" la base en PostgreSQL, c'est l'approche que j'ai tentée dans legi-postgres à l'aide de l'outil pgloader. ca permet de convertir le fichier SQLite en - de 10 mins puis de le rendre accessible via un client psql, gérer des utilisateurs readonly, et bénéficier des fonctionnalité de PostgreSQL... Le repo contient pas mal de code spécifique docker mais l'important c'est surtout ce fichier de conversion : legi.load.

Un exemple de comment on peut exploiter ça ensuite : https://legi.now.sh

[revolunet]

Un accès à PGweb pour consulter la base : https://pgweb.legi.vps.revolunet.com avec ces paramètres :
scheme : postgres://legi:legi@postgres/legi?sslmode=disable

[Seb35]

Merci pour l’accès PGweb. J’ai mis en place hier soir ce que je proposais sur https://sqlite.archeo-lex.fr (format SQLite donc, probablement moins performant que PostgreSQL), et j’y ai aussi mis la base CONSTIT que j’avais créée rapidement pour #33. L’interface PGweb est un peu plus chaleureuse que celle de PHPLiteAdmin.

Reste à voir maintenant ce qu’on propose plus officiellement dans le cadre de Légilibre. Ma proposition initiale d’un sql.legilibre.fr tient toujours, mais je n’ai pas les accès au domaine, et il faudrait voir où/sur quel serveur on installe ça notamment dans le cas d’un PostgreSQL qui demanderait plus de puissance qu’un SQLite.

Aussi, mais c’est probablement l’objet d’une autre issue, ça pourra valoir le coup de regarder (voire de créer) s’il y a des interfaces web plus intuitives pour les gens qui connaissent pas ou pas beaucoup le SQL. J’ai en tête https://query.wikidata.org (language SPARQL) où des exemples de requêtes sont données et qu’il est possible d’adapter un peu, ainsi que Quarry qui permet d’accéder aux bases SQL de Wikipédia/Wikimedia (hors données privées) et qui affiche les requêtes récentes (onglet Recent Queries).

[taniki]

Pour explorer la base sqlite, j'utilise datasette. Ca me semble être une bonne piste pour proposer un accès en lecture et une API minimale.

[taniki]

https://datasette.11d.im/legi/ bon c'est pas fou fou sur l'instance minimum de scaleway (dev-s)

[fgallaire]

Il me semble surtout que vu la taille de la base de donnée il est très simple de mettre à genou le serveur avec une seule requête

[taniki]

il y a un système de timeout qui devrait arrêter la requête. J'ai mis à 10 secondes pour voir mais c'est à 1 seconde par défaut. Au pire, cela bloque les accès concurrents.

[Seb35]

Out of the box, la base SQLite n’a que peu d’index, donc les requêtes sont très longues. Pour ma part, je rajoute les index suivants :

CREATE INDEX textes_versions_nature ON textes_versions (nature);
CREATE INDEX textes_versions_etat ON textes_versions (etat);
CREATE INDEX textes_versions_date_debut ON textes_versions (date_debut);
CREATE INDEX textes_versions_date_fin ON textes_versions (date_fin);
CREATE INDEX textes_versions_num ON textes_versions (num);
CREATE INDEX textes_versions_nor ON textes_versions (nor);
CREATE INDEX textes_versions_date_texte ON textes_versions (date_texte);
CREATE INDEX textes_versions_cid ON textes_versions (cid);
CREATE INDEX textes_versions_mtime ON textes_versions (mtime);
CREATE INDEX articles_section ON articles (section);
CREATE INDEX articles_num ON articles (num);
CREATE INDEX articles_etat ON articles (etat);
CREATE INDEX articles_date_debut ON articles (date_debut);
CREATE INDEX articles_date_fin ON articles (date_fin);
CREATE INDEX articles_cid ON articles (cid);
CREATE INDEX sommaires_element ON sommaires (element);
CREATE INDEX sommaires_parent ON sommaires (parent);

Sinon effectivement datasette est une bonne première interface, c’est améliorable je trouve mais c’est déjà bien, et plus user-friendly que mon PHPLiteAdmin.