Development #66620
utiliser une table parallèle pour les "magictoken"
0%
Description
Lors de la saisie d'une demande les infos de celles-ci sont associées à un "magictoken", qui est conservé/passé dans les pages, pour en fin de saisie récupérer les infos et les enregistrer dans une demande. Le grand plan dans #24635#note-6 serait de ne pas avoir ce stockage parallèle des données, de les avoir directement en brouillon dans la table formdata. Mais je n'ai jamais avancé sur ce plan parce qu'il y a plein de subtilités à gérer et pas assez de temps :/
Une autre approche serait possible, en restant plus proche de la logique actuelle, en séparant juste la partie "magictokens" de la table des sessions (en se préoccupant uniquement de l'SQL).
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Frédéric Péters il y a presque 2 ans
- Lié à Bug #65004: Ticket chapeau champs obligatoires vides à la soumission ajouté
Mis à jour par Frédéric Péters il y a presque 2 ans
- Fichier 0001-sql-store-transient-data-in-a-specific-table-66620.patch 0001-sql-store-transient-data-in-a-specific-table-66620.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Voilà ça se passe avec la modification de la classe sql.Session pour implémenter ses propres méthodes add_magictoken, get_by_magictoken, remove_magictoken, qui plutôt que se baser sur un dictionnaire magictokens stocké dans la session se basent sur des infos d'une table transient_data (id, session_id, data, last_update_time) posée sur le côté.
Par rapport au problème de perte de données, ici on charge/enregistre la donnée "magictoken" uniquement dans les pages qui font appel à magictoken (= pas de risque qu'une session dans un autre onglet sur une autre page / demande écrase quoique ce soit); et les accès parallèles qui accèdent au magictoken, ce sont autosave/live, qui ont ignore_session=True, qui ne doivent déjà plus être le problème.
Mis à jour par Lauréline Guérin il y a presque 2 ans
def add_magictoken(self, token, data):
super().add_magictoken(token, data) # 1
if not self.id:
self.store() # 2
(1) le super fait:
if not self.magictokens:
self.magictokens = {}
self.magictokens[token] = data
(2) et le store de Session fait:
# store transient data
for v in (self.magictokens or {}).values():
v.store()
On ne risque pas de se retrouver à faire un store sur un dict ?
Mis à jour par Frédéric Péters il y a presque 2 ans
En effet et les tests ne passent jamais dans ce if not self.id que j'ai posé trop théoriquement, j'ai modifié la branche pour faire
+ def add_magictoken(self, token, data): + assert self.id + super().add_magictoken(token, data) + self.magictokens[token] = TransientData(id=token, session_id=self.id, data=data) + self.magictokens[token].store()
Mis à jour par Benjamin Dauvergne il y a presque 2 ans
'''CREATE TABLE %s (id varchar PRIMARY KEY,
session_id varchar,
Une fois n'est pas coutume dans w.c.s., je pense qu'on peut se permettre d'utiliser une clé étrangère, i.e remplacer la déclaration de la colonne session_id par
session_id VARCHAR REFERENCES sessions(id) ON DELETE CASCADEça évitera d'avoir à gérer un nettoyage explicite.
Mis à jour par Frédéric Péters il y a presque 2 ans
Avec cette modif CASCADE + un test supplémentaire test_transient_data_removal.
Mis à jour par Frédéric Péters il y a presque 2 ans
Mis à jour par Benjamin Dauvergne il y a presque 2 ans
- Statut changé de Solution proposée à Solution validée
Ok, faut que ça vive en recette.
Mis à jour par Frédéric Péters il y a presque 2 ans
- Statut changé de Solution validée à Résolu (à déployer)
(je tag/déploie une fois le build passé)
commit 844617f9330aa71bf71e9a4498c36da44b64ed69
Author: Frédéric Péters <fpeters@entrouvert.com>
Date: Sat Jun 25 11:16:02 2022 +0200
sql: store transient data in a specific table (#66620)
Mis à jour par Transition automatique il y a presque 2 ans
- Statut changé de Résolu (à déployer) à Solution déployée
sql: store transient data in a specific table (#66620)