j’ai ajouté un group by sur l’attribut d’un objet métier.
quand les données sont “pliées”, l’affichage de ma liste est rapide (environ 1 seconde). quand je veux déplier un bloc contenant 145 lignes, l’affichage dure 5 secondes … quand j’affiche la liste dépliée (je sélectionne une autre liste et je reviens sur celle dépliée), l’affichage dure aussi 5 secondes …
quand je suis instructeur, les stagiaires en cours peuvent être + de 8000 … là on passe à 10 secondes d’affichage …
j’ai mis un index en base pour essayer d’améliorer mais ça ne change pas grand chose.
puis pour chaque groupe ouvert, les N premières pages ouvertes (si objet paginé) de façon asynchrone
Du coup, il faut tracer les requêtes SQL (LOG_SQL_USER=yes) puis faire des “explain” pour vérifier l’indexation / temps d’exécution. Il est possible que certains indexes manquent dans vos jointures (full scan…)
A minima, il faut ajouter 1 index non-unique sur les attributs du group-by (et toutes vos foreign-key si simplicité ne les a pas créées).
10 secondes pour ramener 8000 lignes ? il faut paginer vos listes pour ne pas tout charger à l’écran.
il faut regarder le temps SQL / par exemple mettre une trace dans le preSearch + postSearch
réseau / via debugger Chrome onglet Réseau
affichage UI / à mon avis négligable sauf si une ligne continent des textes longs + images
les index sont tous créés.
en ce qui concerne la pagination, je fait un this.getGrant().setMaxRows(10) dans le preSearch et j’ai toujours 20 lignes par group by. je l’ai positionné dans le initList(), le résultat est le même.
il faut surement changer le min rows.
l’utilisateur peut choisir un min et un max dans sa session, ou par code :
grant.setMinRows
grant.setMaxRows
Attention ça va modifier cette valeur pour toute la session / toutes les listes, donc ce n’est pas la bonne approche.
Si la liste est bien paginée 10 ou 20 ne change pas grand chose (par rapport à 8000), le problème vient des requetes SQL, merci de nous donner les logs SQL et l’explain plan de votre requête longue pour analyse.
