Legi sous PostgreSQL?
Bonjour,
est-il prévu de mettre legi sous une autre base de donnée que SDLite
Oui et non, je l'envisage depuis longtemps mais ce n'est pas une priorité, je ne suis même pas convaincu que ce soit une bonne idée.
Le fork https://github.com/SocialGouv/dila2sql gère à la fois PostgreSQL et SQLite.
Bonjour
Merci pour cette reponse rapide. Pour quelles raisons ce ne serai pas une bonne idée? J'ai l'impression que permettre l'utilisation d'une base multi-utilisateur (en plus de sqlite) ne pourrais pas faire de mal, mais je n'ai peut-être pas tout les éléments.
Le 15 septembre 2019 15:00:02 GMT+02:00, "Charly C." [email protected] a écrit :
Oui et non, je l'envisage depuis longtemps mais ce n'est pas une priorité, je ne suis même pas convaincu que ce soit une bonne idée.>
Le fork https://github.com/SocialGouv/dila2sql gère à la fois PostgreSQL et SQLite.>
-- > You are receiving this because you authored the thread.> Reply to this email directly or view it on GitHub:> https://github.com/Legilibre/legi.py/issues/69#issuecomment-531563569
Gérer plusieurs variantes de SQL nécessite d'ajouter une couche d'abstraction ou de dédoubler certaines requêtes, ça a un coût en temps de développement et de maintenance et ça peut avoir un impact sur les performances.
J’ai testé le fork dila2sql (qui m’intéressait pour la gestion de JORF, cf #54). Le schéma SQL est le même. Sur les performances (critère qui m’importe), je suis déçu : sur une base SQLite, dila2sql importe à 40 records/s (avec DILA2SQL_MAX_PROCESSES=1 pour éviter la concurrence entre processes sur une même base SQLite) alors que legi.py importe à 5000 records/s.
En mode synchrone, dila2sql crée des transactions et commite à chaque record, j’ai essayé de commiter une fois sur 20, et la vitesse augmente à 50 records/s. dila2sql utilise peewee, j’imagine que c’est en grande partie le responsable puisque le code de lecture du .tar.gz et du XML est en grande partie pareil, même s’il y a un peu plus d’instructions pour gérer les spécificités de KALI.