Produits Entr'ouvert » Passerelle

L'idée c'était de taper une date, et d'avoir les dates, mais si on a un datetime on pourrait alors le range devrait être différent, genre cinq minutes avant → cinq minutes après ? et/ou début et inverser le tri ?

Étendre le commentaire "just a date" et y poser quelque chose de l'ordre "just a date, display all events for that date".

Pour l'autre situation, seconds=1, ça ne fait pas un peu court ? (genre taper seconds=60) ? (ou faire ça uniquement sur le date.second==0 ?)

Mmm, en fait ma lecture initiale était différente, je n'avais pas fait gaffe à :

qs = qs.filter(timestamp__lte=date, timestamp__gt=date - datetime.timedelta(days=1))

J'imaginais la plage restreinte selon qu'on soit sur date, date heure/minute, date heure/minute/secondes; genre,

if date.hour == 0 and date.minute == 0 and date.second == 0:
    qs = qs.filter(timestamp__gte=date, timestamp__lt=date + datetime.timedelta(days=1))
elif date.second == 0:
    qs = qs.filter(timestamp__gte=date, timestamp__lt=date + datetime.timedelta(seconds=60))
else:
    qs = qs.filter(timestamp=date)

(j'ai du mal à me concentrer et à comprendre ces différences gte/lt, +, -, par rapport à l'origine.)

Et moi j'avais dit que la borne haute ne sert à rien, on a la pagination pour ça mais l'ordre devrait être du plus vieux au plus récent forcément sinon c'est con (le même ordre que dans un fichier de log donc) (d'ailleurs la description du ticket est fausse on affiche du plus récent au plus vieux ce qui est idiot justement).

Arriver sur une page où les lignes affichées correspondent aux plus récentes garde un certain sens; et avoir l'ordre qui change au moment de la recherche, ça peut être bizarre. (note que inverser le tri était déjà noté dans mon premier commentaire) (idéalement ça se combine avec au moins un indicateur du tri sur la colonne).

Mais ici je trouve qu'à la recherche d'une date avoir les logs correspondant à cette date, ça a du sens, chercher une heure précise et avoir les logs lui correspondant, aussi.

Frédéric Péters a écrit :

Arriver sur une page où les lignes affichées correspondent aux plus récentes garde un certain sens; et avoir l'ordre qui change au moment de la recherche, ça peut être bizarre. (note que inverser le tri était déjà noté dans mon premier commentaire) (idéalement ça se combine avec au moins un indicateur du tri sur la colonne).

Sûr, à la rigueur ça je comprends.

Mais ici je trouve qu'à la recherche d'une date avoir les logs correspondant à cette date, ça a du sens, chercher une heure précise et avoir les logs lui correspondant, aussi.

Pour rester simple on peut inverser l'ordre en cas de recherche sans date mais c'est vrai que c'est surprenant ou alors on muscle un peu la pagination (et ListView ne sera plus suffisant dans ce cas), on permet soit de spécifier une date avant ou après la page et on pose une ancre en fin de page sur laquelle on pointe tout le temps (en ajoutant #end à tous les liens vers les logs).

• sans filtre sur la date on utilise -timestamp et on fait un reversed() sur le résultat avant de le passer au template
• en fin de template on a un <span id="end"/> sur lequel on peut pointer
• quand on cherche par date ça ajoute un after=<timestamp>
• dans tous les cas: on conserve l'id et timestamp de la première et de la dernière ligne et on a deux liens:
  • un lien "Avant" qui ajoute ?before=<timestamp-première-ligne>,<id-première-ligne> quand on reçoit ça la vue fait .filter(Q(timestamp__lt=timestamp)|(Q(timestamp=timestamp,id__lt=<id-première-ligne>)).order_by('-timestamp','-id')[:200]) et on affiche en reversed()
  • un lien "Après" qui ajoute ?after=<timestamp-dernière-ligne>,<id-dernière-ligne> quand on reçoit ça la vue fait
    .filter(Q(timestamp__gt=timestamp)|(Q(timestamp=timestamp,id__gt=<id-dernière-ligne).order_by('timestamp', 'id')[:200] et on affiche dans l'ordre qu'on reçoit

(je ne modifierai pas mon patch)

Ça peut être intéressant aussi d'avancer/reculer par demi-page (i.e. par paquet de 100 lignes et pas de 200).