Produits Entr'ouvert » w.c.s.

Est-ce que ce ne serait pas plus simple d'utiliser l'héritage entre tables de PG ? Vu que c'est une vue sur un "UNION ALL" d'un sous-ensemble des colonnes des tables formdata_* ? J'entrevois un souci pour conserver la gestion des primary key au niveau des tables filles (peut-être possible d'avoir deux colonnes mais peut-être connais-tu une solution (peut-être que c'est aussi simple que d'avoir un global_id GENERATED AS IDENTITY au niveau table parent, et un "id GENERATED AS IDENTITY" au niveau de chaque table fille).

L'héritage des tables aurait un résultat qui ne serait guère différent de la solution actuelle avec une vue.
On retrouve des traces de la nomenclature objet de PostgreSQL sur certaines tables système. Par exemple la liste des relations est dans la table système pg_class.
Chaque table est une classe, chaque enregistrement est une instance de la classe. L'héritage des tables n'est pas différent de l'héritage des classes en C++, Java ou Python : quand les tables formdata_42 et formdata_73 héritent de la table formdata_generic, une sélection sur formdata_generic va faire l'union entre formdata_42 et formdata_73 et les "caster" en formdata_generic. On peut aussi stocker des objets directement dans formdata_generic.
La vue actuelle est une sorte d'héritage fait main...

Ok, je pensais que la table parente centralisait les champs communs (comme l'héritage en Django) et qu'il y avait une sorte de FK cachée entre les deux (basé sur la PK ou l'oid ou que sais-je) mais en fait non, c'est juste du sucre syntaxique, chaque table fille contient toute les colonnes définies au niveau du parent.

Mais donc ok si on peut maintenir de façon transparente via des trigger une table commune pourquoi pas; la solution sinon ce serait de faire comme l'héritage Django mais ce serait forcément plus chiant de migrer vers ça que des triggers, on y gagnerait un dédoublonnage des données mais ce ne sont pas ces colonnes qui nous coûtent cher, ce sont les fxxx et autres workflow_data.

Mille erreurs parce que CREATE OR REPLACE TRIGGER pas encore dispo, j'imagine que ça se remplace facilement par un DROP puis CREATE.

Juste pour la discussion, plutôt que d'avoir une fonction trigger par table formdata, avoir une table formdata_all_forms alimentée depuis wcs_all_forms (qui ne bougerait pas) via un UPSERT, dans une tâche de fond toutes les 5 secondes ou déclenché par une fonction trigger unique simple, ce ne serait pas plus simple à maintenir ?

Juste pour la discussion, plutôt que d'avoir une fonction trigger par table formdata, avoir une table formdata_all_forms alimentée depuis wcs_all_forms (qui ne bougerait pas) via un UPSERT, dans une tâche de fond toutes les 5 secondes ou déclenché par une fonction trigger unique simple, ce ne serait pas plus simple à maintenir ?

Je ne vois pas quelle serait la forme de ce trigger unique, ni la forme de cette table "formdata_all_forms". Le soucis qui nécessite une fonction trigger par table est simple : toutes les données de wcs_all_forms ne sont pas présentes dans une forme exploitable dans la base de données. Par exemple formdef.name me semble introuvable dans la DB, de même pour la liste des status qui constituent un endpoint...

Avec la dernière version de la branche, on est sur 8 tests qui échouent. Deux que j'ai du mal à lancer en local pour le moment, et six pour lesquels je n'ai pas encore de solution à part "réécrire toute la gestion des migrations SQL" (pas sûr que ce soit une bonne idée).
Au passage, concernant les migrations SQL : sont-elles exécutées application éteinte ou à chaud ?

Au passage, concernant les migrations SQL : sont-elles exécutées application éteinte ou à chaud ?

Globalement à froid (dans wcs.service, ExecStartPre=/usr/bin/wcs-manage migrate).

_~~

Avec la dernière version de la branche, on est sur 8 tests qui échouent. Deux que j'ai du mal à lancer en local pour le moment, et six pour lesquels je n'ai pas encore de solution à part "réécrire toute la gestion des migrations SQL" (pas sûr que ce soit une bonne idée).

Je ne mappe pas vraiment les 8 et 6 dont tu parles.

J'en vois cinq qui ont des explicites cur.execute('DROP VIEW wcs_all_forms CASCADE'), mais c'est du code de test, il peut être remplacé par n'importe quoi qui ferait pareil.

test_form_category_management_roles qui échoue sur

E           psycopg2.errors.UniqueViolation: ERREUR:  la valeur d'une clé dupliquée rompt la contrainte unique « wcs_all_forms_pkey »
E           DETAIL:  La clé « (object_type, formdef_id, id)=(formdata, 1, 1) » existe déjà.

On pourrait avoir un explicite DELETE FROM wcs_all_forms dans Formdef.wipe().

Ensuite, celui qui

  type = '<class 'psycopg2.errors.DuplicateTable'>', value = 'ERREUR:  la relation « wcs_category_foo » existe déjà

je serais à dire qu'on peut dégager les vues sur les catégories.

Dans les logs,

/tmp/tox-jenkins/wcs/wip/60552-wcs_all_forms-table/3/py3-django22-codestyle-pylint-coverage/lib/python3.9/site-packages/webtest/app.py:675: AppError
----------------------------- Captured stderr call -----------------------------
[2022-01-19 11:37:56] exception caught
Exception:
  type = '<class 'psycopg2.errors.DuplicateTable'>', value = 'ERREUR:  la relation « wcs_category_foo » existe déjà
'

Là-dessus je commentais plus haut "je serais à dire qu'on peut dégager les vues sur les catégories.".

Stack trace (most recent call first):
  File "/var/lib/jenkins/workspace/ip_wip_60552-wcs_all_forms-table/wcs/sql.py", line 1579, in do_global_views
  1577     for category in wcs.categories.Category.select():
  1578         name = get_name_as_sql_identifier(category.url_name)[:40]
> 1579         cur.execute(
  1580             '''CREATE VIEW wcs_category_%s AS SELECT * from wcs_all_forms
  1581                         WHERE category_id = %s'''

ou juste 'CREATE OR REPLACE VIEW' ici, peut-être.

Il reste un commentaire # XXX TODO: make me dynamic, please ? dans wcs/sql.py

Ah oui je n'étais pas trop sûr de ce que Pierre entendait là, je me suis dit que c'était peut-être centraliser la liste des colonnes, et utiliser cette liste pour écrire la requête ici mais aussi celle dans recreate_trigger(), mais dans le doute j'ai laissé.

Pour info durée exécution migrate sur saas/test, 2 minutes.

root@db1:~# grep 'CREATE TABLE IF NOT EXISTS wcs_all_forms' /var/log/postgresql/postgresql-11-main.log | wc -l
189
root@db1:~# grep 'CREATE TABLE IF NOT EXISTS wcs_all_forms' /var/log/postgresql/postgresql-11-main.log | head -1
2022-03-26 09:25:01.145 CET [9896] wcs@wcs_beaulieu_test_eservices_montpellier3m_fr LOG:  statement: CREATE TABLE IF NOT EXISTS wcs_all_forms (
root@db1:~# grep 'CREATE TABLE IF NOT EXISTS wcs_all_forms' /var/log/postgresql/postgresql-11-main.log | tail -1
2022-03-26 09:26:58.103 CET [13136] wcs@wcs_formulaires_multipref_minint_test_entrouvert_org LOG:  statement: CREATE TABLE IF NOT EXISTS wcs_all_forms (

Pour info durée exécution migrate sur saas/test, 2 minutes.

+ la migration qui a suivi pour créer les triggers, 5 minutes.

Frédéric Péters a écrit :

Pour info durée exécution migrate sur saas/test, 2 minutes.

+ la migration qui a suivi pour créer les triggers, 5 minutes.

J'imagine que ça dépend du volume des données (nombre de demandes) et que donc, en prod, ça risque d'être nettement supérieur.

A priori le premier "2 minutes" dépend du nombre de demandes; le deuxième "5 minutes" dépend du nombre de démarches.

(mais oui ça prendra du temps en prod)

Automatic expiration