Tech : Ajout de données contextuelles dynamique pour les trigger FieldsHistory()

🤔 Pourquoi ?

Afin d'avoir une solution générique à plusieurs problèmes :

1. Pour la carte ETQ PH je peux signaler que le candidat n’est plus sans solution on veux savoir par qui et quand la modification du nouveau drapeau a été fait, ça aurais pu être fait de plein d'autre manière mais je me suis dit que c'était aussi bien de réutiliser (et améliorer) le FieldsHistory() qui avais déjà été mis en place pour asp_uid
2. Discussion récente pendant la descente sur le fait d'avoir un historique des modifications, en particulier le qui, pour certain champs de JobSeekerProfile().

🍰 Comment ?

Utilisation de la fonction PG set_config() pour avoir une "variable" locale aux transactions. Voir aussi https://www.postgresql.org/docs/17/runtime-config-custom.html.

Utilisation de cette variable (avec gestion d'erreur) dans la fonction appelée par le trigger. Voir aussi : https://www.postgresql.org/docs/17/errcodes-appendix.html

Le contexte est enregistré ou mis à jour automatiquement grace à connection.execute_wrapper() de Django.

Un middleware qui initialise le contexte de base.

NB : Je me suis pas mal appuyé sur ce qui est fait dans https://github.com/AmbitionEng/django-pghistory, c'est beaucoup plus complexe mais la logique de base est proche.

🏁 Reste à faire

• Peut-être de tests plus poussés pour triggers.context()
• Tester proprement la concurrence pour _set_context_connection_wrapper(), j'utilise des threading.Event() donc ça devrait être bon quand on est en multiprocess mais à mon avis faudrait les attacher à la variable _context : threading.local() ou peut-être directement sur connection ?
• Initialisation du contexte pour les managements commands
• Vérifier que les premiers écrits sont toujours pertinents, par exemple test_context_when_it_is_never_set devrait changé car la différence de comportement est normalement maintenant gérer dans la fonction PG directement.