Fonctions et requêtes SQL pour tableau de bord Metabase #372
Conversation
ggounot
changed the title
ggounot
force-pushed
the
sql-metabase-dashboard
branch
from
e892651
to
d42e79b
Compare
| @@ -1,4 +1,6 @@ | |||
| fileignoreconfig: | |||
There was a problem hiding this comment.
Pourquoi on a des ignore qui nous obligent à versionner ce fichier ?
There was a problem hiding this comment.
C'est Talisman qui considère les migrations comme risquées et empêche le commit si on n'ajoute pas un ignore. Il doit y avoir moyen de configurer Talisman pour éviter ça.
| AND is_active = true | ||
| ); | ||
| END; | ||
| $$ language plpgsql; |
There was a problem hiding this comment.
Je suis assez perplexe en général sur l'utilisation de procédures stockées dans le domaine applicatif, mais là c'est pour aider côté analytics.
Mais même avec ça je suis pas à l'aise sans une bonne dose de documentation et de justification.
Il y a souvent des alternatives aux P.S., car elles obfusquent les règles métiers en les plaçant dans la couche DB (à n'utiliser qu'en dernier recours, comme les triggers)
There was a problem hiding this comment.
1/ Pour commencer, je n'arrive pas à faire fonctionner la requête qu'encapsule la procédure stockée.
2/ Je pense que passer par une procédure stockée n'est pas une solution viable pour adresser des soucis de requête / stabilité / perf de Metabase.
Je ne trouve nulle part dans la doc, une description sur "comment invoquer une procédure stockée". La seule occurrence de "procedure" un peu proche (sur 2) est juste un court passage (1 ligne) pour expiquer qu'il faut donner le droit EXECUTE au role / user qui permet d'accéder à la base source. Mais rien de plus.
De ce que je comprends et connais de la philosophie MB, je pense qu'il faut plutôt créer une vue ou une question (cf. section queries/metabase/03-questions).
| SELECT COUNT(*) > 0 AS has_admin | ||
| FROM structures_structuremember | ||
| LEFT JOIN users_user ON structures_structuremember.user_id = users_user.id | ||
| WHERE structure_id = structure_id_input | ||
| AND is_admin = true | ||
| AND is_valid = true | ||
| AND is_active = true |
There was a problem hiding this comment.
❌ J'ai tenté d'exécuter cette requête sur la base de staging, et apparemment elle ne fonctionne pas, car le champs structure_id_input n'existe pas.
# query
dora_back_xxx=> SELECT COUNT(*) > 0 AS has_admin FROM structures_structuremember LEFT JOIN users_user ON structures_structuremember.user_id = users_user.id WHERE structure_id = structure_id_input AND is_admin = true AND is_valid = true AND is_active = true;
# result
ERROR: column "structure_id_input" does not exist
LINE 1: ...mber.user_id = users_user.id WHERE structure_id = structure_...There was a problem hiding this comment.
C'est une procédure stockée et structure_id_input est le paramètre.
|
🤦♂️ Je n'avais pas vu que la PR est en statut |
|
@ikarius @jbuget ceci est le début d'une solution pour créer et optimiser les requêtes du TDB Metabase public. Sachant qu'on veut reproduire les règles logiques complexes qu'on a dans le front-end, j'ai pensé à éclater les différents éléments en sous-requêtes ou procédures si un paramètre est nécessaire. Ce n'est qu'un début de proposition et il faudrait qu'on en discute ensemble. Je suis d'accord que mettre autant de logique métier dans des requêtes est une mauvaise idée. Sans doute le plus propre serait de déporter la logique du front-end sur le back-end et remplacer le TDB public Metabase par notre propre TDB qui pourrait alors utiliser la logique métier codée sur le back. |
structure_has_admin