L'index prend ~20% de la taille de la table (la table fait un peu plus de 100%Mo, et l'index un peu plus de 20Mo), mais permet de diviser par 10 les requêtes qui filtrent sur la date des ventes.
Ca concerne notamment les requêtes db faites sur les pages suivantes :
- les appels à facture (~75ms → ~3ms)
- les ventes d'un club (entre 300ms et 450ms → entre 10ms et 15ms)
- le top conso des comptoirs (sur le Foyer, ~90ms → ~9ms)
- les dernières opérations d'un comptoir (sur le Foyer, ~130ms → ~1.5ms
J'aurais bien aimé mettre également un index sur la troncature au mois de la date, mais c'est compliqué à mettre en place étant donné que postgres ne prend des index que sur des expressions immuables et que, comme elle dépend de la timezone (qui peut changer), la fonction date_trunc n'est pas immuable.
* Remove ability to refill from counters
* Fix bug where you could refill without any board member on a BAR
* Add a warning message explaining why refilling are disabled
* Move settings.SITH_COUNTER_PAYMENT_METHOD to counter.apps.PAYMENT_METHOD
* Move student cards to an accordion on counter click
* Make cash default refilling option
* Disable bank selection option in refilling if CHECK are not allowed
* Disable refilling with CHECK from the frontend
Le timeout se fait en une seule requête et la récupération de l'état des comptoirs en une seule requête aussi. Grâce à ça, on peut en grande partie retirer le cache pour l'affichage de l'état des comptoirs, ce qui a des implications excellentes en termes d'UX (comme le fait que la redirection vers la page de comptoir ou d'activité aura plus une apparence de truc aléatoire)
En raison de la manière dont le timeout marche et de l'activité des comptoirs, la notion de "comptoir inactif" n'est pas intuitive. Un comptoir est ouvert ou fermé. Point.