Vie privée : mise à jour des dates pivot de la notification [2/2]

[vincentporte]

🤔 Pourquoi ?

Certaines dates utilisées pour déclencher la notification d'archivage ne sont pas appropriées.
Elles sont remplacées par des dates "métiers" plus précises (ou supprimées)

Périmètre :

• JobApplication : created_at
• JobApplicationTransitionLog : timestamp

⚠️ tests sensible à leur date d'execution mis à jour dans cette PR :

• test_archive_jobseeker_with_approval
• test_archive_not_eligible_jobapplications_of_inactive_jobseekers_after_grace_period

[notion-workspace]

💨 Vie privée : mise à jour des conditions d’archivage sur les groupes GPS

[tonial]

l'utilisation de logs__timestamp pourrait alourdir fortement la requête. Est-ce que tu as testé ?

[vincentporte]

@tonial, ces 2 tests selon que nous utilisons logs__timestamp ou une sous-requête directement sur JobApplicationTransitionLog, sortent des temps d'execution similaire.

question : cette comparaison est-elle signifiante pour toi ?

inactive_since = timezone.now() - INACTIVITY_PERIOD

test 1 : one subquery

recent_job_application = JobApplication.objects.filter(Q(created_at__gt=inactive_since) | Q(logs__timestamp__gt=inactive_since),job_seeker_id=OuterRef("pk"))
User.objects.filter(kind='job_seeker').filter(~Exists(recent_job_application)).count()
638778

connection.queries
[{'sql': 'SELECT COUNT(*) AS "__count" FROM "users_user" WHERE ("users_user"."kind" = \'job_seeker\' AND NOT EXISTS(SELECT 1 AS "a" FROM "job_applications_jobapplication" U0 LEFT OUTER JOIN "job_applications_jobapplicationtransitionlog" U1 ON (U0."id" = U1."job_application_id") WHERE ((U0."created_at" > \'2023-08-30 05:57:23.660350+00:00\'::timestamptz OR U1."timestamp" > \'2023-08-30 05:57:23.660350+00:00\'::timestamptz) AND U0."job_seeker_id" = ("users_user"."id")) LIMIT 1))',
  'time': '1.760'}]

test 2 : two subqueries

recent_job_application = JobApplication.objects.filter(job_seeker_id=OuterRef("pk"),created_at__gt=inactive_since)
recent_transitions = JobApplicationTransitionLog.objects.filter(job_application__job_seeker_id=OuterRef("pk"), timestamp__gt=inactive_since)
User.objects.filter(kind='job_seeker',upcoming_deletion_notified_at__isnull=True).filter(~Exists(recent_job_application), ~Exists(recent_transitions)).count()

connection.queries
[{'sql': 'SELECT COUNT(*) AS "__count" FROM "users_user" WHERE ("users_user"."kind" = \'job_seeker\' AND "users_user"."upcoming_deletion_notified_at" IS NULL AND NOT EXISTS(SELECT 1 AS "a" FROM "job_applications_jobapplication" U0 WHERE (U0."created_at" > \'2023-08-30 05:57:23.660350+00:00\'::timestamptz AND U0."job_seeker_id" = ("users_user"."id")) LIMIT 1) AND NOT EXISTS(SELECT 1 AS "a" FROM "job_applications_jobapplicationtransitionlog" U0 INNER JOIN "job_applications_jobapplication" U1 ON (U0."job_application_id" = U1."id") WHERE (U1."job_seeker_id" = ("users_user"."id") AND U0."timestamp" > \'2023-08-30 05:57:23.660350+00:00\'::timestamptz) LIMIT 1))',
  'time': '1.685'}]

[tonial]

C'est plus une comparaison avec sans que j'avais en tête (par rapport aux gains de performance que tu as obtenus avant (23 -> 0.8s)

[vincentporte]

Temps d'exécution en milli secondes

time.time()

master	one subquery with OR	two subqueries
8.086442947387695	7.432460784912109	8.379220962524414
8.732318878173828	8.600711822509766	8.518457412719727
7.921695709228516	7.796764373779297	8.507251739501953
7.441520690917969	8.025884628295898	8.31747055053711

process_time()

master	one subquery with OR	two subqueries
8.876145000002111	8.003589000001199	9.772650000002159
7.457892000001465	7.081010000000276	7.616086999998828
6.589542000000392	6.787968000001143	7.803689999999364
6.524236000000627	6.829377999999053	8.220791000002947

Pas de variation incroyable dans un sens ou dans l'autre. La version à 2 sous-requetes distinctes est pénalisante.

Détail surprenant, les résultats sont inversés entre la version master et la version à une sous-requête, selon qu'on prend time() ou process_time()

[tonial]

du coup c'est bon avec une seule subquery 👍

[tonial]

Il faudrait revoir les noms des variables de tests pour plus de clarté.
Le test est super au demeurant :)