Project

General

Profile

Actions

Bug #1901

closed

Affichage très long du composant

Added by David Lesimple over 10 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Urgent
Start date:
04/18/2011
Due date:
% Done:

100%

Estimated time:
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.

Actions #1

Updated by Nicolas Eysseric over 10 years ago

  • Status changed from New to 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.

Actions #2

Updated by David Lesimple over 10 years ago

  • File Silverpeas-dump.zip added
Actions #3

Updated by Nicolas Eysseric over 10 years ago

  • File deleted (Silverpeas-dump.zip)
Actions #4

Updated by Nicolas Eysseric over 10 years ago

  • Status changed from Feedback to Assigned
  • Assignee set to Miguel Moquillon
Actions #5

Updated by Nicolas Eysseric over 10 years ago

  • Target version set to Version 5.7
Actions #6

Updated by Miguel Moquillon over 10 years ago

  • Status changed from Assigned to In progress...
Actions #7

Updated by Miguel Moquillon over 10 years ago

  • Target version changed from Version 5.7 to 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).

Actions #8

Updated by Nicolas Eysseric over 10 years ago

  • Target version changed from Version 5.6.1 to Version 5.7
Actions #9

Updated by Nicolas Eysseric over 10 years ago

  • Subject changed from Affichage très long du composant. to Affichage très long du composant
  • Status changed from In progress... to Closed
  • % Done changed from 0 to 100

OK. Validé.

Actions

Also available in: Atom PDF