| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
parties entre parenthèse. Les nouveaux cas de tests passent avec succès.
|
|
|
|
possédant pas de semestre. Les tests rajoutés au commit précédent
passent donc avec succès.
|
|
erreurs de parsage. Ces erreurs sont liées au fait qu’elles ne
possèdent pas de semestre.
Exemple avec le groupe M1 GC (toutes sections et semestres
confondus) :
Attendu :
* mention : M1 GC
* semestre :
* sous-groupe :
Obtenu avec la regex actuelle :
* mention : M1
* semestre :
* sous-groupe : C
|
|
parties entre parenthèse. Les nouveaux cas de tests passent avec succès.
|
|
|
|
|
|
|
|
|
|
possédant pas de semestre. Les tests rajoutés au commit précédent
passent donc avec succès.
|
|
erreurs de parsage. Ces erreurs sont liées au fait qu’elles ne
possèdent pas de semestre.
Exemple avec le groupe M1 GC (toutes sections et semestres
confondus) :
Attendu :
* mention : M1 GC
* semestre :
* sous-groupe :
Obtenu avec la regex actuelle :
* mention : M1
* semestre :
* sous-groupe : C
|
|
|
|
datetime.combine()"
This reverts commit 37d80d84d8ce6cb0a17a0e4179e4c7a453f7fcc2.
|
|
|
|
|
|
|
|
|
|
|
|
cours d’une salle pour économiser les requêtes et augmenter les performances
|
|
rapide à exécuter sur de gros volumes de données. On aura peut-être
besoin d’utiliser un double index pour augmenter encore plus les
performances.
La requête liste tous les cours commençant avant la fin de
l’intervalle et finissant après le début de l’intervalle, en excluant
les cours n’ayant pas de salle assignée. On récupère ensuite la liste
des salles de ces cours, et on inverse le contenu de la liste. On trie
ensuite les cours par leur nom.
|
|
Pour chaque salle, on compte tous les cours commençant avant la fin de
l’intervalle entré par l’utilisateur et finissant après le début de
cet intervalle. Tous les cours correspondant à cette requête
se trouvent au moins en partie sur l’intervalle.
On sélectionne ensuite les salles n’ayant pas de cours correspondant à
la requête précédente.
|
|
On y créée sept salles, avec différents agencements de cours :
0. Le cours se finit dans l’intervalle sélectionné
1. Le cours se commence dans l’intervalle
2. Combinaison de 0. et de 1.
3. Le cours commence avant et fini après l’intervalle
4. Le cours commence et fini pendant l’intervalle
5. Un cours se finit avant et un autre commence après
6. Aucun cours
liste des salles.
Normalement, seules les salles des cas cinq et six doivent se
retrouver dans la liste des salles.
|
|
|
|
|
|
|
|
Pour cela, on avait besoin d’insérer un objet vTimezone dans l’en-tête
du fichier, ce qui est assez fastidieux. À la place, on met une
valeur x-wr-timezone dans les en-têtes.
Ajout de valeurs calscale, method, x-wr-calname et x-wr-caldesc aux ICS.
Revert "Bon fuseau horaire dans les ICS."
This reverts commit e2bc777f7f988cba945c027aaa27d98aa3913a71.
|
|
Pour cela, on avait besoin d’insérer un objet vTimezone dans l’en-tête
du fichier, ce qui est assez fastidieux. À la place, on met une
valeur x-wr-timezone dans les en-têtes.
Ajout de valeurs calscale, method, x-wr-calname et x-wr-caldesc aux ICS.
Revert "Bon fuseau horaire dans les ICS."
This reverts commit e2bc777f7f988cba945c027aaa27d98aa3913a71.
|
|
|
|
Les bases de données stockent et renvoient seulement des dates en
UTC. Django inscrit cette information dans les objets datetime, par
conséquent les dates inscrites sur les templates étaient
automatiquement converties à l’heure indiquée dans la configuration.
Or, les ICS sont générées avec une librairie tierce (icalendar), et ne
tient donc pas compte de la configuration de Django. Le module inscrit
donc des dates UTC dans les ICS. C’est sans conséquences, car l’heure
est correcte, juste décalée avec une information de fuseau horaire. Un
bon client iCalendar est censé convertir les heures de lui-même en
fonction des préférences du systèmes. Seulement certains d’entre eux
affichent aussi le fuseau horaire d’origine.
|
|
Les bases de données stockent et renvoient seulement des dates en
UTC. Django inscrit cette information dans les objets datetime, par
conséquent les dates inscrites sur les templates étaient
automatiquement converties à l’heure indiquée dans la configuration.
Or, les ICS sont générées avec une librairie tierce (icalendar), et ne
tient donc pas compte de la configuration de Django. Le module inscrit
donc des dates UTC dans les ICS. C’est sans conséquences, car l’heure
est correcte, juste décalée avec une information de fuseau horaire. Un
bon client iCalendar est censé convertir les heures de lui-même en
fonction des préférences du systèmes. Seulement certains d’entre eux
affichent aussi le fuseau horaire d’origine.
|
|
Lien pour retourner à la liste des groupes sur la page des emplois du temps
Lien pour retourner à la liste des années sur la page de liste des mentions
Lien pour retourner à la liste des mentions sur la page des groupes
Lien pour retourner à la liste des années sur la liste des salles
Lien pour accéder à la liste des salles sur la page principale
Lien pour retourner à la liste des salles sur le formulaire QSJPS
|
|
|
|
|
|
La requête est assez longue à s’effectuer sur SQLite, mais pas sur PostgreSQL
|
|
si un cours n’en a pas, au lieu de se baser sur le nombre de salles
d’un cours pour faire ce choix.
Suppression du préchargement des salles lorsqu’on demande les cours
d’une salle. Cela permet de réduire le nombre de requêtes effectuées.
|
|
salles. Réduit le nombre de requêtes à effectuer ainsi que le temps de traitement.
|
|
les emplois du temps des salles
|
|
précédentes
|
|
|
|
|
|
ni une salle
|
|
|
|
|
|
Renommage de la template contenant le formulaire
|
|
|
|
|
|
|
|
|
