search

qwat / qwat-data-model

TEKSI Water module (project QWAT) - PostgreSQL / postgis Datamodel
https://www.teksi.ch
23 stars 25 forks source link

update CH VD SIRE extension #217

Closed 3nids closed 6 years ago

3nids commented 6 years ago

Ajout des vues pour l'export vers SIRE. Il manque encore quelques conversions (voir https://github.com/qwat/QWAT/issues/247 )

Les colonnes code_sire des VL sont encore dans le tronc commun de QWAT. Les vues d'export sont dans un schéma dédié.

Pour faire fonctionner les scripts de réécriture de vues, il faut exporter la variable d'environnement QWAT_CH_VD_SIRE=ON

Prêt pour review.

ponceta commented 6 years ago

@3nids Si on voulait administrer les permissions dans une extension, on placerait les scripts également dans le dossier de l'extension?

haubourg commented 6 years ago

@ponceta tu parles d'extension postgresql qui s'installe avec un create extension xxx; ?

attention, une extension présuppose les droits d'admin complète du serveur de base de données. Utiliser des extensions reviendrait à créer un verrou de plus pour l'installation et la maintenance.

ponceta commented 6 years ago

@haubourg non, je parle d'extension au sens modèle de données qwat, d'où le titre de la pull request de @3nids.

Je parle ici uniquement des droits qui sont attribués de manière globale dans QWAT via https://github.com/VilleDePully/qwat-data-model/blob/master/roles.sql

ponceta commented 6 years ago

@3nids Que penses-tu d'ajouter un appel conditionnel dans le script d'initialisation de qwat init_qwat.sh vers extensions/ch_vd_sire/sire.sh

Cela permettrait potentiellement de tester la capacité du PUM à gérer les extensions/personnalisations. L'extension SIRE étant commune à l'ensemble des partenaires, pour moi c'est le choix idéal, même si c'est une vaudoiserie.

3nids commented 6 years ago

@ponceta pas sûr de vouloir mettre l'extension par défaut. Mais on peut mettre ça dans Travis. Cela va par contre générer un peu de travail pour la validation de PUM (~1/2 jour?). Je pense qu'il faudrait un accord du groupe.

ponceta commented 6 years ago

@3nids, je pense également que ça doit être discuté. Laissons peut-être passer la mise en production du PUM chez tous et on en rediscute. L'extension ne doit en aucun cas être installée par défaut. Mais si elle est testée, cela apporterait au moins aux entités qui l'utilisent la confiance qu'elle s'intègre bien dans l'architecture QWAT. #SIRE_certified. La question se posera également avec l'ajout des codes de correspondance SIA.

haubourg commented 6 years ago

Effectivement, mon souci de compréhension avec ce nouveau méncanisme d'extensions, c'est d'avoir une procédure claire et compatible PUM quelques soient les configurations de migration. (utilisateurs / travis ) Une activation de l'extension par variable d'environnement ne me semble pas jouer simplement avec le système de versionnement.

Si on prend le workflow actuel travis on a:

1- initialisation d'une base de référence par dump complet en 1.2.6, donc sans l'extension 2- initialisation d'une base cible par le code (init) en version courante. Selon qu'on active ou pas la variable d'environnement, on aura la structure d'extension 3- application des deltas sur la base de départ et vérification de cohérence avec la base cible.

Dans ce jeu, la comparaison avec la 1.2.6 de référence échouera., sauf si un delta spécifique à Travis ajoute explicitement l'extension. Mais dans ce cas, cela revient à avoir une customisation client qui applique l'extension. Bref, j'ai pas les idées claires là dessus, et la notion d'extension me semble rajouter un cran de complexité de plus à un outil déjà complexe qu'est le PUM, avec double validation de cohérence delta / initialisation.

@elemoine @sylvainbeo @lbartoletti preneurs de vos avis, sachant qu'on doit démarrer le chantier https://github.com/qwat/qwat-data-model/issues/151 pour consolider une mode d'emploi pour les customisation client.

3nids commented 6 years ago

Il faut effectivement que le dump de départ contienne l'extension. Ensuite, les deltas spécifiques à l'extension s'appliquent par variables d'environnement (ou option).

haubourg commented 6 years ago

@3nids Could the issue https://github.com/qwat/qwat-data-model/issues/237 be addressed in that PR?

3nids commented 6 years ago

@haubourg @kandre j'ai corrigé les code sire pour le PE 100. Du coup, il faut un delta. @haubourg peux-tu contrôler que c'est ok pour le delta (j'ai ajouté un delta supplémentaire pour 1.3.2, est-ce correct?)

haubourg commented 6 years ago

@3nids parfait le delta. Vous êtes prêts pour le merge?

3nids commented 6 years ago

toujours!

elemoine commented 6 years ago

Je ne comprends pas comment l'extension ch_vd_sire doit être installée. J'ai essayé d'exécuter le script sire.sh juste après init_qwat.sh mais ça plante :

$ export SRID=21781
$ export PGSERVICE=qwat
$ ./extensions/ch_vd_sire/sire.sh
CREATE SCHEMA
ALTER TABLE
ALTER TABLE
ALTER TABLE
ALTER TABLE
ALTER TABLE
ALTER TABLE
ALTER TABLE
ALTER TABLE
ALTER TABLE
ALTER TABLE
psql:/home/elemoine/src/qwat-data-model/extensions/ch_vd_sire/views/conduite.sql:31: ERROR:  column "qwat_ext_ch_vd_sire_remarque" does not exist
LINE 4:   , qwat_ext_ch_vd_sire_remarque || remark AS remarque

Tout d'abord, à noter que j'ai déjà du patcher sire.sh pour qu'il prenne PGSERVICE en compte:

diff --git a/extensions/ch_vd_sire/sire.sh b/extensions/ch_vd_sire/sire.sh
index 146bc02..d3a2283 100755
--- a/extensions/ch_vd_sire/sire.sh
+++ b/extensions/ch_vd_sire/sire.sh
@@ -6,5 +6,5 @@ set -e
 DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

 psql -c "CREATE SCHEMA IF NOT EXISTS qwat_ch_vd_sire;"
-psql -v ON_ERROR_STOP=1 -v SRID=$SRID -f ${DIR}/sire_columns.sql
+psql service=$PGSERVICE -v ON_ERROR_STOP=1 -v SRID=$SRID -f ${DIR}/sire_columns.sql
 ${DIR}/insert_views.sh

Mais ça ne suffit pas. extensions/ch_vd_sire/views/conduite.sql plante parce que la vue qwat_od.vw_export_pipe n'a pas la colonne qwat_ext_ch_vd_sire_remarque. C'est normal, étant donné que la vue qwat_od.vw_export_pipe n'a pas été recréée après l'ajout des colonnes (sire_columns.sql).

Du coup, pour moi, le script sire.sh ne peut pas fonctionner.

Quelle est donc la procédure pour activer l'extension ch_vd_sire ? Faut-il utiliser le script sire.sh ? Ou autre chose ? Je note que sire.sh est le seul script à exécuter sire_columns.sql, donc je me dis qu'il doit forcément être utilisé ?

Sauf erreur la doc ne contient rien concernant la mise en place de l'extension ch_vd_sire.

Merci pour toute information sur le sujet.

lbartoletti commented 6 years ago

Par ailleurs sire_columns.sql requiert postgresql 9.6+ (ADD COLUMN [IF NOT EXISTS] est arrivé en 9.6, cf doc 9.5 et 9.6

elemoine commented 6 years ago

@lbartoletti l'utilisation de ADD COLUMN IF NOT EXISTS était dans ma branche de travail uniquement (celle que tu étais en train de tesetr), et pas dans master. Donc ton commentaire ne s'applique pas ici. Ceci étant j'ai aussi modifié ma branche de travail pour ne pas reposer sur cette fonctionnalité qui n'existe qu'à partir de PG 9.6. Merci pour le test !

3nids commented 6 years ago

@elemoine l'idée est que l'on doit lancer sire.sh + insert_views.sh Ensuite, lors d'une migration la variabe QWAT_CH_VD_SIRE =ON doit être déclarée et les vues sont recrées. Voir ici