Development #24424
Mis à jour par Benjamin Dauvergne il y a plus de 5 ans
Suite du #23348.
Ça bourrine trop la base de donnée et empêche de journaliser les modifications correctement (on ne peut plus archive le WAL, on est obligé de le supprimer), il faut trouver une autre manière de conserver la date du dernier saut pour calculer l'expiration.
-Dans Dans le #23348 je soutiens que c'est du cache dans la mesure où en l'absence de la valeur (en cas de perte de celle-ci) on peut se baser sur formdata._last_update_time / evolutions[-1].time / formdata.receipt_time sans que ce soit un problème si juste après on repose un last_update_time dans un stockage volatile (en gros on va boucler un peu plus vite en cas de perte du stockage volatile, mais ça n'aura pas de conséquence grave). Peut-être que je me trompe donc si quelqu'un voit un cas ou l'absence de la donnée exacte serait préjudiciable, dites moi.- moi.
-Le Le seul besoin que je verrai de matérialiser ça en base c'est si on avait une requête optimisée pour obtenir la liste des formdata avec last_update_time plus ancien qu'un certain point (ça augmenterait les perfs du CRON un poil), mais on n'a pas ça et on s'en passe bien pour l'instant, et même si on le voulait on pourrait toujours lister les valeurs depuis le cache (en utilisant une queue de priorité dans redis par exemple) en plus de faire la requête SQL.-
Nouvean plan :
Le stockage du last_jump_datetime pour chaque évolution ne semble pas avoir d'utilité car seul certaines évolutions se verront assigner un @last_jump_datetime@ différent de leur @time@
* créer une nouvelle table @formdata_..evolution_last_jump_datetime@ avec deux colonnes @evolution_id et @last_jump_datetime@
* faire la jointure lors des select, si NULL renvoyer @evolution.time@ à la place
* mettre à jour via un accesseur sur FormData @set_last_jump_datetime()@ qui en SQL ira updater la bonne table et seulement celle là.
La même idée pourrait être utilisée pour last_update_time sur FormData.
SQL.
Ça bourrine trop la base de donnée et empêche de journaliser les modifications correctement (on ne peut plus archive le WAL, on est obligé de le supprimer), il faut trouver une autre manière de conserver la date du dernier saut pour calculer l'expiration.
-Dans Dans le #23348 je soutiens que c'est du cache dans la mesure où en l'absence de la valeur (en cas de perte de celle-ci) on peut se baser sur formdata._last_update_time / evolutions[-1].time / formdata.receipt_time sans que ce soit un problème si juste après on repose un last_update_time dans un stockage volatile (en gros on va boucler un peu plus vite en cas de perte du stockage volatile, mais ça n'aura pas de conséquence grave). Peut-être que je me trompe donc si quelqu'un voit un cas ou l'absence de la donnée exacte serait préjudiciable, dites moi.- moi.
-Le Le seul besoin que je verrai de matérialiser ça en base c'est si on avait une requête optimisée pour obtenir la liste des formdata avec last_update_time plus ancien qu'un certain point (ça augmenterait les perfs du CRON un poil), mais on n'a pas ça et on s'en passe bien pour l'instant, et même si on le voulait on pourrait toujours lister les valeurs depuis le cache (en utilisant une queue de priorité dans redis par exemple) en plus de faire la requête SQL.-
Nouvean plan :
Le stockage du last_jump_datetime pour chaque évolution ne semble pas avoir d'utilité car seul certaines évolutions se verront assigner un @last_jump_datetime@ différent de leur @time@
* créer une nouvelle table @formdata_..evolution_last_jump_datetime@ avec deux colonnes @evolution_id et @last_jump_datetime@
* faire la jointure lors des select, si NULL renvoyer @evolution.time@ à la place
* mettre à jour via un accesseur sur FormData @set_last_jump_datetime()@ qui en SQL ira updater la bonne table et seulement celle là.
La même idée pourrait être utilisée pour last_update_time sur FormData.
SQL.