Projet

Général

Profil

Bug #66374

IntegrityError: ERREUR: la valeur d'une clé en conflit rompt la contrainte d'exclusion « tstzrange_constraint »

Ajouté par Sentry Io il y a presque 2 ans. Mis à jour il y a presque 2 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
17 juin 2022
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

Description

https://sentry.entrouvert.org/entrouvert/publik/issues/61784/

ExclusionViolation: ERREUR:  la valeur d'une clé en conflit rompt la contrainte d'exclusion « tstzrange_constraint »
DETAIL:  La clé (desk_id, tstzrange(start_datetime, _end_datetime))=(42, ["2022-06-18 07:00:00+00","2022-06-18 08:00:00+00")) est en conflit avec la clé existante (desk_id, tstzrange(start_datetime, _end_datetime))=(42, ["2022-06-18 07:00:00+00","2022-06-18 08:00:00+00")).
CONTEXT:  instruction SQL « UPDATE agendas_event SET _ignore_reason = NULL WHERE id = OLD.event_id »
fonction PL/pgSQL set_ignore_reason()...
  File "django/db/backends/utils.py", line 84, in _execute
    return self.cursor.execute(sql, params)

IntegrityError: ERREUR:  la valeur d'une clé en conflit rompt la contrainte d'exclusion « tstzrange_constraint »
DETAIL:  La clé (desk_id, tstzrange(start_datetime, _end_datetime))=(42, ["2022-06-18 07:00:00+00","2022-06-18 08:00:00+00")) est en conflit avec la clé existante (desk_id, tstzrange(start_datetime, _end_datetime))=(42, ["2022-06-18 07:00:00+00","2022-06-18 08:00:00+00")).
CONTEXT:  instruction SQL « UPDATE agendas_event SET _ignore_reason = NULL WHERE id = OLD.event_id »
fonction PL/pgSQL set_ignore_reason()...
(17 additional frame(s) were not displayed)
...
  File "django/db/backends/utils.py", line 67, in execute
    return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
  File "django/db/backends/utils.py", line 76, in _execute_with_wrappers
    return executor(sql, params, many, context)
  File "django/db/backends/utils.py", line 84, in _execute
    return self.cursor.execute(sql, params)
  File "django/db/utils.py", line 89, in __exit__
    raise dj_exc_value.with_traceback(traceback) from exc_value
  File "django/db/backends/utils.py", line 84, in _execute
    return self.cursor.execute(sql, params)

Fichiers


Demandes liées

Lié à Chrono - Bug #44676: rendez-vous : empecher au niveau base la création de conflit sur des rdvFermé01 juillet 2020

Actions
Lié à Chrono - Bug #66394: pl/pgsql, l'enregistrement « new » n'a pas de champs « _end_datetime »Fermé18 juin 2022

Actions

Révisions associées

Révision b64dc050 (diff)
Ajouté par Lauréline Guérin il y a presque 2 ans

agendas: move sql migration code in dedicated file (#66374)

Révision 8d7abfc5 (diff)
Ajouté par Lauréline Guérin il y a presque 2 ans

agendas: fix pg function set_ignore_reason on desk deletion (#66374)

Historique

#1

Mis à jour par Lauréline Guérin il y a presque 2 ans

  • Projet changé de Suivi des traces à Chrono
#2

Mis à jour par Lauréline Guérin il y a presque 2 ans

  • Assigné à mis à Lauréline Guérin
#3

Mis à jour par Lauréline Guérin il y a presque 2 ans

  • Lié à Bug #44676: rendez-vous : empecher au niveau base la création de conflit sur des rdv ajouté
#4

Mis à jour par Lauréline Guérin il y a presque 2 ans

On est sur le cas d'une suppression de desk avec suppression par django des objets liés en cascade;

Django supprime bien le desk avant les bookings et les events, mais les contraintes FK doivent être débranchées car lorsque la procédure set_ignore_reason fait l'update du champ _ignore_reason sur la table event, desk_id n'est pas null (et la contrainte tstzrange_constraint n'est alors pas respectée)

J'ai repris la procédure set_ignore_reason pour ajouter un cas spécifique sur TG_OP = 'DELETE'

#5

Mis à jour par Frédéric Péters il y a presque 2 ans

  • Statut changé de Solution proposée à Solution validée

Je serais pour qu'on pose l'sql dans un fichier séparé, pour ne pas avoir de question sur la manière dont il se trouve packagé/installé, ça pourrait rester dans un .py, on aurait chrono/agendas/sql.py avec dedans

SET_IGNORE_REASON = """ 
CREATE OR REPLACE FUNCTION set_ignore_reason() RETURNS TRIGGER AS $$
    BEGIN
        IF (TG_OP = 'INSERT') THEN
            IF NEW.cancellation_datetime IS NOT NULL THEN
                UPDATE agendas_event SET _ignore_reason = 'cancel' WHERE id = NEW.event_id;
...

ça faciliterait ainsi la visualisation des changements apprtés à l'SQL; au-delà de la note dans le commentaire (cas spécifique sur TG_OP = 'DELETE').

Bref,

+        ELSIF (TG_OP = 'DELETE') THEN
+            UPDATE agendas_event SET _ignore_reason = 'delete' WHERE id = OLD.event_id;
+            RETURN OLD;

Ok avec ça.

Et mon commentaire sur la création d'un sql.py ou autre, je me le garde pour discussion.

#6

Mis à jour par Lauréline Guérin il y a presque 2 ans

On a déjà du sql dans chrono/agendas/sql, pour d'autres triggers; j'ai déplacé le code (0001) puis appliqué le correctif (0002)

#7

Mis à jour par Frédéric Péters il y a presque 2 ans

Super, ça me permet de voir que je ne comprends pas l'inversion old/new du trigger...

#8

Mis à jour par Lauréline Guérin il y a presque 2 ans

on est en AFTER INSERT OR UPDATE OR DELETE; donc pour INSERT et UPDATE les données à jour sont dans NEW.
(et je ne sais pas pourquoi j'ai écrit OLD pour != INSERT il y a 2 ans ...)
Mais fondamentalement ça ne change pas grand chose, on ne s'amuse pas à changer event_id sur un booking.

#9

Mis à jour par Frédéric Péters il y a presque 2 ans

Vendu, passons ça ce cycle.

#10

Mis à jour par Frédéric Péters il y a presque 2 ans

  • Statut changé de Solution proposée à Solution validée
#11

Mis à jour par Lauréline Guérin il y a presque 2 ans

  • Statut changé de Solution validée à Résolu (à déployer)
commit 8d7abfc5cab4e4d66bb54f3b0c8e73523f16f82a
Author: Lauréline Guérin <zebuline@entrouvert.com>
Date:   Fri Jun 17 17:14:46 2022 +0200

    agendas: fix pg function set_ignore_reason on desk deletion (#66374)

commit b64dc05083e2a4add64d5aff9d36425366ddb7be
Author: Lauréline Guérin <zebuline@entrouvert.com>
Date:   Fri Jun 17 17:11:37 2022 +0200

    agendas: move sql migration code in dedicated file (#66374)
#12

Mis à jour par Transition automatique il y a presque 2 ans

  • Statut changé de Résolu (à déployer) à Solution déployée
#13

Mis à jour par Lauréline Guérin il y a presque 2 ans

  • Lié à Bug #66394: pl/pgsql, l'enregistrement « new » n'a pas de champs « _end_datetime » ajouté
#14

Mis à jour par Transition automatique il y a plus d'un an

Automatic expiration

Formats disponibles : Atom PDF