Retirer l’heure de fin des diagnostics d’éligibilité et utiliser uniquement la date#5210
Conversation
|
Ça fait un gros UPDATE sur 1M de lignes, qui met 2-3 secondes à s’exécuter sur ma machine. Sûrement un peu moins sur notre super base de données musclée. |
francoisfreitag
changed the title
xavfernandez
left a comment
xavfernandez
left a comment
There was a problem hiding this comment.
Cela me semble être une bonne idée 👍
| migrations.AlterField( | ||
| model_name="eligibilitydiagnosis", | ||
| name="expires_at", | ||
| field=models.DateField(db_index=True, verbose_name="date d'expiration"), |
There was a problem hiding this comment.
Est-ce que la migration se passe bien ?
Dans le sens où un diag qui expire à "JOUR 23h50UTC" (donc "JOUR+1 00h50 CET" actuellement) doit avoir comme date d'expiration convertie en "JOUR+1".
Si ce n'est pas le cas, il faudrait idéalement d'abord adapter les heures pour que la conversion se fasse bien ensuite.
There was a problem hiding this comment.
On s’en fiche, on n’est pas à un jour près sur les dates. Le diag a une durée très arbitraire, pas grave si on arrondit mal dans un cas limite.
https://www.notion.so/plateforme-inclusion/Mise-en-conformit-du-fonctionnement-des-dates-du-PASS-IAE-prolongation-suspension-7b0dbd5e87e045f1acc2f2352e0e3aec
Ça pourrait lui faire du bien de découper la migration en deux pour n'avoir un LOCK que sur une seule table à la fois ? |
|
Il n’y a que 10K diag d’éligibilité GEIQ, ils ne pèsent pas dans la balance. |
|
C’est aussi une table peu mise à jour. |
| created_at = models.DateTimeField(verbose_name="date de création", default=timezone.now, db_index=True) | ||
| updated_at = models.DateTimeField(verbose_name="date de modification", auto_now=True, db_index=True) | ||
| expires_at = models.DateTimeField(verbose_name="date d'expiration", db_index=True) | ||
| expires_at = models.DateField(verbose_name="date d'expiration", db_index=True) |
There was a problem hiding this comment.
Je me demande si un petit help_text expliquant que le diag n'est donc plus valide à cette date ne serait pas le bienvenu.
There was a problem hiding this comment.
Pour préciser que la date est exclusive ?
There was a problem hiding this comment.
Oui exclusive sur la validité et inclusive sur l'expiration 😬
There was a problem hiding this comment.
😁 J’ai essayé de tourner ça clairement.
francoisfreitag
force-pushed
the
ff/expires-at
branch
4 times, most recently
from
e19e1b7 to
ba98dba
Compare
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
francoisfreitag
force-pushed
the
ff/expires-at
branch
from
ba98dba to
d5b0093
Compare
Using a datetime doesn’t make much sense, we’re dealing with administrative periods. test_update_diagnosis_extend_the_validity_only_when_we_have_the_same_author_and_the_same_criteria was modified because the updated diagnosis (only author) has a pretty good chance of expiring the same day.
francoisfreitag
force-pushed
the
ff/expires-at
branch
from
d5b0093 to
5ed6b97
Compare
2 participants
🤔 Pourquoi ?
Un
datetimen’a pas vraiment de sens pour les diagnostics d’éligibilité. On n’affiche jamais les heures/minutes/secondes aux utilisateurs, et la date d’expiration est administrative, ce n’est pas un point dans le temps.