Produits Entr'ouvert » Chrono

Il y a ce bout qui pose question parce qu'il y a plus le tri par 'start_datetime' :

-        next_exception = (
-            self.timeperiodexception_set.filter(start_datetime__gte=now()).order_by('start_datetime').first()
-        )
-        if next_exception:
-            return [next_exception]
+        for exception in self.timeperiodexception_set.all():
+            if exception.start_datetime < now():
+                # exception starts in the past, skip it
+                continue
+            # returns the first exception found
+            return [exception]

Mais en fait je ne comprends déjà pas ce bout avant ton patch, get_exceptions_within_two_weeks qui renvoie les exceptions des deux prochaines semaines, sauf quand finalement ça renvoie la prochaine exception au delà de deux semaines.

Bref sur la perte de ce tri, c'est bien fait vu et sans effets de bord ?

L'ordering par défaut au niveau du model est 'start_datetime'. Si on veut pouvoir utiliser le prefetch posé dans la vue, il ne faut pas rajouter de l'ordering dans cette méthode.

Mais en fait je ne comprends déjà pas ce bout avant ton patch, get_exceptions_within_two_weeks qui renvoie les exceptions des deux prochaines semaines, sauf quand finalement ça renvoie la prochaine exception au delà de deux semaines.

La méthode avait déjà ce comportement avant que je la modifie :)
J'ai ajouté des tests unitaires/de non régression avant d'y toucher.

si tu veux, j'ajouterai un peu d'entropie dans les tests unitaires avant de merger: faire en sorte que les exceptions ne soient pas dans le même ordre lorsqu'elles sont triées par pk/date d'écriture dans la DB (ce qui est généralement le comportement d'un select sans ordering) et par start_datetime :)