Retirer l’heure de fin des diagnostics d’éligibilité et utiliser uniquement la date #5210
Conversation
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.
|
Ç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
| 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. |
| @@ -66,7 +66,7 @@ class AbstractEligibilityDiagnosisModel(models.Model): | |||
| ) | |||
| 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.
| "expires_at": "2022-08-08T10:57:46.994Z", | ||
| "job_seeker": 21, | ||
| "updated_at": "2022-02-08T10:57:47.028Z" | ||
| { |
There was a problem hiding this comment.
Tu as utilisé le script itou/fixtures/django/dumpdata.sh ? Ou au moins jq . --sort-keys "$file" ?
J'ai l'impression que l’indentation change 
| @@ -76,12 +76,12 @@ def __str__(self): | |||
|
|
|||
| def save(self, *args, **kwargs): | |||
| if not self.expires_at: | |||
| self.expires_at = self.created_at + relativedelta(months=self.EXPIRATION_DELAY_MONTHS) | |||
| self.expires_at = timezone.localdate(self.created_at) + relativedelta(months=self.EXPIRATION_DELAY_MONTHS) | |||
There was a problem hiding this comment.
Est-ce que mettre une vérification sur le type expires_at et raise en test si on récupère un datetime ne serait pas une bonne idée ?
🤔 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.