Produits Entr'ouvert » Chrono

TL;DR : j'ai beaucoup d'objets TimePeriodException (~1000) et beaucoup d'objets Event (pareil, ~1000). Est-ce qu'une requête qui sélectionne tous les évènements pris dans au moins un intervalle d'une exception peut poser problème niveau perf, ou pas ? Sachant que cette requête est jouée en asynchrone, mais régulièrement.

Alternativement, est-ce que c'est vraiment utile de pouvoir changer la date d'une récurrence d'un évènement ? (vs l'annuler et créer un évènement unitaire)

• On peut ajouter des exceptions aux évènements récurrents
• Cet ajout va conduire à virer des évènements couverts par la période de l'exception
• À l'inverse une suppression d'exception va potentiellement entraîner la création les évènements auparavant empêchés
• Dernier point, les exceptions pouvant arriver de plein d'endroits (ajout direct, calendrier d'indispo, syncho d'un ICS), plutôt que d'aller exécuter du code à tous ces endroits on joue la mise à jour des évènements en asynchrone, via cron

C'est là qu'arrive le bug de ce ticket, cette mise à jour asynchrone vire un évènement qu'elle n'aurait pas dû virer. Et puis comme elle l'a viré, elle le recrée derrière.

1. Récupération à la volée des évènements en prenant en compte les exceptions (déjà codé par ailleurs et délégué à dateutil, d'où le côté facile)
2. Comparaison avec les évènements en base
3. Suppression des évènements en base en trop

Le principe c'est que si il y a une nouvelle exception qui chevauche des évènements déjà présents, on ne les trouvera pas lors de l'étape 1., donc ils seront supprimés.

Le bug c'est qu'ici la récupération à la volée donne l'évènement avec sa date initiale, or l'évènement en base a sa date modifiée, donc la comparaison des deux foire et l'évènement se retrouve supprimé (le bug n'a donc rien à voir avec les exceptions).

• Simple, on interdit de modifier la date d'une récurrence. Si besoin il faut l'annuler + créer un évènement unique.
• Plus compliqué, corriger ce code. Il s'agirait de regarder les évènements en base, de faire l'intersection avec les exceptions, et de supprimer ce qui se trouve pris dedans.

Merci pour le long debug.

Valentin Deniaud a écrit :

• Simple, on interdit de modifier la date d'une récurrence. Si besoin il faut l'annuler + créer un évènement unique.

Pour moi c'est ok : on annule avec une exception et on crée un événement unique. Faudra quand même vérifier avec les autres CPF qui utilisent Chrono plus que moi et en particulier Stef.

• Évènement à 14h, changé à 16h
• Exception à 16h
• Suppression de l'évènement par le cron
• Ajout de l'évènement de 14h par le cron <-- fail

Le contournement ici ce serait de ne pas supprimer l'évènement mais de l'annuler, ça garderait une trace permettant de ne pas le recréer derrière. Mais on a vraiment pas envie de se retrouver avec quantité d'évènements annulés à chaque ajout d'exceptions, l'affichage serait vraiment moche.

Bref, ça fait 8 mois que le bug existe (combinaison de #52112 + #50561), c'est à dire 8 mois que personne n'a jamais pu modifier la date d'une récurrence . J'attends confirmation de Stef mais pour moi c'est assez pour considérer la fonctionnalité comme inutile.

Valentin Deniaud a écrit :

J'attends confirmation de Stef mais pour moi c'est assez pour considérer la fonctionnalité comme inutile.

Vu avec Stef, finalement on conserve, parce qu'en fait l'alternative « annuler l'évènement et en recréer un autre » que j'imaginais n'en est pas une, parce que ça ferait perdre les réservations. Ou l'alternative serait un workflow compliqué qui aille rejouer les réservations, alors n'y pensons pas.

Par contre on peut s'autoriser un détour par le monde réel : si on va manuellement modifier la date d'un évènement, c'est pour qu'il ait lieu. Donc ça paraît légitime de dire qu'un tel évènement sorte du circuit de suppression automatique des évènements couverts par les exceptions.

Tout ça pour dire, une autre solution pas trop compliquée au problème c'est d'exclure d'emblée dans la fonction de mise à jour les évènements dont la date a été modifiée.

Automatic expiration