Projet

Général

Profil

Actions

Bug #1901

fermé

Affichage très long du composant

Ajouté par David Lesimple il y a presque 13 ans. Mis à jour il y a presque 13 ans.

Statut:
Closed
Priorité:
Urgent
Assigné à:
Début:
18/04/2011
Echéance:
% réalisé:

100%

Temps estimé:
Navigateur:
Tous
Votre version de Silverpeas:
5.5.4
Système d'exploitation:
Votre base de données:
Toutes
Livraison en TEST:
Livraison en PROD:

Description

Lorsque l'almanach comporte plusieurs centaines d'évènements ou plusieurs milliers (au total)
Il faut entre 10 et plus de 30" pour avoir la liste des évènements du mois.
Apparemment, c'est du au fait que pour chaque évènement, on regarde sa périodicité.
Ce point est bloquant pour les clients qui utilisent beaucoup ce composant (42 instances)
A titre d'exemple, sur mon pc de dev, un almanach de 5700 évènements met plus de 30" pour s'afficher.

Mis à jour par Nicolas Eysseric il y a presque 13 ans

  • Statut changé de New à Feedback

Un dump de la base serait le bienvenu...
Ainsi, une analyse basée sur le profiling du composant permettrait rapidement de détecter et optimiser l'affichage du composant.

Mis à jour par David Lesimple il y a presque 13 ans

  • Fichier Silverpeas-dump.zip ajouté

Mis à jour par Nicolas Eysseric il y a presque 13 ans

  • Fichier Silverpeas-dump.zip supprimé

Mis à jour par Nicolas Eysseric il y a presque 13 ans

  • Statut changé de Feedback à Assigned
  • Assigné à mis à Miguel Moquillon

Mis à jour par Nicolas Eysseric il y a presque 13 ans

  • Version cible mis à Version 5.7

Mis à jour par Miguel Moquillon il y a presque 13 ans

  • Statut changé de Assigned à In progress...

Mis à jour par Miguel Moquillon il y a presque 13 ans

  • Version cible changé de Version 5.7 à Version 5.6.1

Pour corriger le pb de performances, le code a été modifié pour ne charger que les événements dont les occurrences peuvent se dérouler dans la période de temps à afficher (mois ou semaines). Ceci a permis aussi de corriger un bogue non encore remonté : la suppression qui ne se fait pas d'une occurrence donnée d'un événement récurrent avec horaire de début et de fin.

A côté de ceci, la bibliothèque ical4j a été mise à jour à la version stable 1.0. Cette bibliothèque est utilisée pour le calcul des occurrences des événements avec gestion des exceptions dans la récurrence. Ce qui a permit de détecter des pb dans la gestion des dates:
- Des erreurs de saisi des dates dans certains événements ont été détectées: des événements avec une date de fin antérieure à celle du début existent ! Il est nécessaire de corriger ce point en détectant dès la création d'un événement une tentative de saisie incorrecte. Pour les événements existants avec de telles erreurs, je recommande automatiquement d'inverser l'horaire de début avec celui de fin (car je suppose que c'est une inversion du remplissage des champs horaires).
- De plus, pour les événements avec un horaire de début, l'absence d'horaire de fin pose des problèmes de signification. Actuellement, dans fullcalendar, avec de tels événements, l'horaire de fin est calculée à deux heures après celle de l'heure de début. Il faudrait mieux valoriser explicitement l'horaire de fin lorsque ce dernier est absent (à deux heures après celui du début afin d'être compatible avec le comportement précédent de fullcalendar).

Mis à jour par Nicolas Eysseric il y a presque 13 ans

  • Version cible changé de Version 5.6.1 à Version 5.7

Mis à jour par Nicolas Eysseric il y a presque 13 ans

  • Sujet changé de Affichage très long du composant. à Affichage très long du composant
  • Statut changé de In progress... à Closed
  • % réalisé changé de 0 à 100

OK. Validé.

Actions

Formats disponibles : Atom PDF