Produits Entr'ouvert » Chrono

Me suis trompé dans le nom de la branche : https://jenkins.entrouvert.org/job/chrono-wip/job/wip%252F44617-concurrent-events/.

Je pense que le fix serait plutôt:

diff --git a/chrono/api/views.py b/chrono/api/views.py
index 2f0bc6d..284ea1d 100644
--- a/chrono/api/views.py
+++ b/chrono/api/views.py
@@ -169,7 +169,7 @@ def get_all_slots(base_agenda, meeting_type, resources=None, unique=False):
             )
             .exclude(booking__cancellation_datetime__isnull=False)
             # ordering is important for the later groupby, it works like sort | uniq
-            .order_by('desk_id', 'start_datetime')
+            .order_by('desk_id', 'start_datetime', 'meeting_type__duration')
             .values_list('desk_id', 'start_datetime', 'meeting_type__duration')
         )
         # compute exclusion set by desk from all bookings, using

Pour être sûr que start + duration ( = end ) est bien dans le bon ordre

J'étais tombée sur ce cas pour les réservations de ressources, et j'ai pas pensé à vérifier l'existant

Sauf si j'ai rien compris, tout ça me semble contourner le vrai problème, à savoir que deux rendez-vous ont été pris sur le même guichet au même moment, parce qu'on n'a aucune contrainte SQL sur cela et que deux transactions vont être acceptées tranquillement.

Thomas Noël a écrit :

Sauf si j'ai rien compris, tout ça me semble contourner le vrai problème, à savoir que deux rendez-vous ont été pris sur le même guichet au même moment, parce qu'on n'a aucune contrainte SQL sur cela et que deux transactions vont être acceptées tranquillement.

Oui, +1 pour Thomas qui a bien suivi en cours de SQL. Je dirai unicité sur (desk_id, start_datetime) mais faudra un index partiel avec une clause WHERE pour que ça ne s'applique que si cancellation_datetime__isnull=True; à l'endroit de la prise de rendez-vous il faudrait utiliser get-or-create sur (desk_id, start_datetime) on peut ajouter agenda_id mais il découle de desk_id normalement (le schéma n'est pas en forme normale je ne sais laquelle).

PS1: dans un autre ticket, la proposition de Laureline suffit ici (qui est la même que la mienne)
PS2: mais d'abord il faut vérifier si le cas ne s'est pas produit énormément ailleurs avant, sinon la migration ne passera jamais.

Benjamin Dauvergne a écrit :

Je dirai unicité sur (desk_id, start_datetime)

Ca suffira pas totalement (même si c'est déjà ça), on pourra toujours ajouter une résa 13h15-13h30 alors que 13h00-14h00 vient d'être reservé dans la transaction précédente. Je pense que c'est le genre de truc compliqué qu'on ne règle qu'à coup de procédures stockées (et on ne va pas aller vers ça, je pense). Et oui, tout ça est pour un autre ticket.

Mais je ne suis pas super chaud pour appliquer le patch proposé ici : il cache le problème sous le tapis (on ne devrait pas avoir besoin de ce patch si les écritures étaient bien contraintes).

Thomas Noël a écrit :

Benjamin Dauvergne a écrit :

Je dirai unicité sur (desk_id, start_datetime)

Ca suffira pas totalement (même si c'est déjà ça), on pourra toujours ajouter une résa 13h15-13h30 alors que 13h00-14h00 vient d'être reservé dans la transaction précédente. Je pense que c'est le genre de truc compliqué qu'on ne règle qu'à coup de procédures stockées (et on ne va pas aller vers ça, je pense). Et oui, tout ça est pour un autre ticket.

Non il y a aussi des index d'exclusion en Postgresql, mais ça demande que end_datetime soit matérialisé dans la table on ne peut pas demander à postgres de le calculer à la volée depuis meeting_type__duration comme on le fait dans le code.

https://www.postgresql.org/docs/9.4/sql-createtable.html#SQL-CREATETABLE-EXCLUDE

Ça donnerait un truc comme ça :

EXCLUDE USING GIST (desk_id WITH =, tstzrange(start_datetime, end_datetime) WITH &&)

Mais je ne suis pas super chaud pour appliquer le patch proposé ici : il cache le problème sous le tapis (on ne devrait pas avoir besoin de ce patch si les écritures étaient bien contraintes).

En attendant on a aucun moyen d'empêcher ce bug, il faut appliquer ce patch sinon quand le bug arrive ça empêche toute réservation, pour l'instant on peut vivre avec quelques rdv qui se chevauchent plutôt qu'avec des applications qui ne marchent pas.

Benjamin Dauvergne a écrit :

Mais je ne suis pas super chaud pour appliquer le patch proposé ici : il cache le problème sous le tapis (on ne devrait pas avoir besoin de ce patch si les écritures étaient bien contraintes).

En attendant on a aucun moyen d'empêcher ce bug, il faut appliquer ce patch sinon quand le bug arrive ça empêche toute réservation, pour l'instant on peut vivre avec quelques rdv qui se chevauchent plutôt qu'avec des applications qui ne marchent pas.

Ok, allons-y alors. Un mix patch de Lauréline + test d'Emmanuel comme ça tout le monde est content ?