Produits Entr'ouvert » Chrono

Pour simplifier les triggers, et aussi parce qu'on utilise souvent cette information (qu'on va chercher à coup d'annotations), j'ai ajouté des compteurs booked_places et booked_waiting_list_places

On pourrait simplifier encore un peu les triggers, et surtout les déclencher moins souvent, en ajoutant une app comme django-readonly-field (https://pypi.org/project/django-readonly-field/), qui garantirait que les compteurs et les bool full/almost_full ne sont pas modifiés par le code.
Mais ça fait une contrib de plus à intégrer.

Lauréline Guerin a écrit :

Pour simplifier les triggers, et aussi parce qu'on utilise souvent cette information (qu'on va chercher à coup d'annotations), j'ai ajouté des compteurs booked_places et booked_waiting_list_places

On pourrait simplifier encore un peu les triggers, et surtout les déclencher moins souvent, en ajoutant une app comme django-readonly-field (https://pypi.org/project/django-readonly-field/), qui garantirait que les compteurs et les bool full/almost_full ne sont pas modifiés par le code.

Je ne comprends pas très bien comment ça ferait pour ne pas déclencher le trigger sur event ? Dès qu'il y aura un update même partiel il est déclenché, non ? Pour moi les déclenchements des triggers ne coûtent pas trop cher de toute façon, sauf s'ils se mettent à écrire d'autres lignes que celles qu'on est en train de modifier ou font des SELECT un peu complexe.

Mais ça fait une contrib de plus à intégrer.

Le seul cas d'amplification d'écriture qui me parait possible c'est sur le

    SET
        booked_places = (
            SELECT COUNT(*) FROM agendas_booking b
            WHERE b.event_id = e_id AND b.cancellation_datetime IS NULL AND b.in_waiting_list = false
        ),
        booked_waiting_list_places = (
            SELECT COUNT(*) FROM agendas_booking b
            WHERE b.event_id = e_id AND b.cancellation_datetime IS NULL AND b.in_waiting_list = true
        )
    WHERE id = e_id;

si vraiment tu veux améliorer ça tu pourrais rajouter une condition au where et utiliser des CTEs:

WITH
        booked_places AS (
            SELECT COUNT(*) AS cnt FROM agendas_booking b
            WHERE b.event_id = e_id AND b.cancellation_datetime IS NULL AND b.in_waiting_list = false
        ),
        booked_waiting_list_places AS (
            SELECT COUNT(*) AS cnt FROM agendas_booking b
            WHERE b.event_id = e_id AND b.cancellation_datetime IS NULL AND b.in_waiting_list = true
        )
    UPDATE agendas_event
    SET
        booked_places = booked_places.cnt,
        booked_waiting_list_places = booked_waiting_list_places.cnt
    FROM booked_places, booked_waiting_list_places
    WHERE id = e_id AND (agendas_event.booked_places <> booked_places.cnt OR agendas_event.booked_waiting_list_places <> booked_waiting_list_places.cnt)

Mais vraiment ça ne me parait pas critique (à moins qu'il y ait énormément d'écritures sur les lignes de agendas_booking sans rapport avec les places et les listes d'attente).

Ça me parait donc super mais vu que ça touche quand même à une mécanique complexe je veux bien un autre survol.

Amélioration des triggers (CTE et SELECT INTO)

Je ne comprends pas très bien comment ça ferait pour ne pas déclencher le trigger sur event ?

Si on a la garantie que les champs booked_places, booked_waiting_list_places, full et almost_full ne sont jamais écrasés par chrono, alors on peut se passer du recalcul des compteurs places dans la fonction update_event_full_fields
On peut aussi conditionner le déclenchement de update_event_full_fields_trigger aux changements de valeur de booked_places, booked_waiting_list_places, places et waiting_list_places seulement.
Et le déclenchement de update_event_places_fields_trigger à update avec changement de valeur de in_waiting_list ou cancellation_datetime, insert et delete seulement.

Je ne pense pas non plus qu'il y ait tant de mouvements que cela sur les tables event et booking. Je préfère éviter d'introduire une nouvelle dépendance pour le moment.

si vraiment tu veux améliorer ça tu pourrais rajouter une condition au where et utiliser des CTEs

J'ai fait ça, au moins pour éviter de déclencher update_event_full_fields_trigger sur l'anonymisation des réservations.

Toujours ok pour moi.

j'ai laissé le sql revert dans la migration (peu de lignes)

commit 0b53360c0c5eaa08c5d3ec0339e430e106d340d9
Author: Lauréline Guérin <zebuline@entrouvert.com>
Date:   Mon Aug 16 15:59:01 2021 +0200

    agendas: trigger full and places event fields (#54747)