Nous souhaitons mettre à disposition une limitation sur la fonctionnalité de modification en masse sur l’ensemble des objets auprès des utilisateurs de l’application.
Pour cela, nous utilisons le Hook preUpdateAll dans une classe commune qui, en fonction de l’utilisateur, instaure une limite avec un nombre de donnée modifiable specifique à chaque utilisateur (en utilisant “hasResponsability(”…")).
Jusqu’ici tout allait bien pour l’ensemble des objets métier, la limitation se fait bien, une pop-up est directement retourné avec un message d’erreur (le return du preUpdateAll en l’occurrence, sauf pour un cas de figure.
Nous rencontrons un problème dans le cas d’un objet dont son code et son template sont hérité (l’objet métier n’a pas d’attribut d’objet à lui mais proviennent tous de l’objet hérité).
Le problème ici est qu’il y a un temps de chargement plutôt long (de calcul des champs peut être ?) avant d’exécuter le preUpdateAll qui après un certain temps s’exécute bien et empêche la MAJ en masse si la limitation est dépassé (pop-up apparait et pas de modification). Cependant pour environs 1300 lignes sélectionnés il y a un temps de chargement d’environs 46s avant que la pop-up de restriction ne s’affiche à l’utilisateur (lui faisant croire probablement que la modification se fait, et je ne parle pas du cas où le nombre de ligne sélectionner est encore plus grand…).
Il n’y a rien “avant” le preUpdateAll appelé par la UI. Avant d’arriver au preUpdateAll, il y a juste le hook canUpdateAll qui est appelé, y faites vous quelque chose ?
Regardez quel appel Ajax met du temps depuis le debugger du navigateur, pour etre sur que c’est bien l’appel au “update all” et pas à autre chose.
Sinon que fait votre hook de compliqué pour limiter l’accès ? ajouter des logs en entrée/sortie pour voir son temps d’exécution interne. L’objet hérité a surement des différences avec le parent, plus de règles de gestion… ?
Après avoir regardé le debugger du navigateur, je constate qu’effectivement il s’agit bien de l’appel Ajax du “upadate all” qui met du temps.
J’ai ajouté des logs pour étudier le temps de traitement des hooks.
Plus finement, il s’agit de la ligne suivante :
“nb = search(false).size();”
En ajoutant des logs dans le hook postSearch (hérité) (seul hook de search implémenté) je constate que ce hook se lance après ce “temps de chargement”.
Peut-être n’ai-je pas identifier une autre cause ?.. Cela dit je tiens à souligner que ce problème n’apparait que pour un objet héritant
faites un simple count() qui fait un simple “select count(*) … where …filters…”
car search(false) donc non paginé ramène toute la table en mémoire (une liste de String[])
que comptez vous exactement ?
Cette solution convient parfaitement et réponds à mon problème en évitant l’appel Ajax “search” qui nous pose quelques problèmes sur notre projet (sujet en cours d’investigation).
On compte le nombre de lignes sélectionné lors d’une mise à jour en masse (pour, selon le profil, empêcher (ou non) la maj selon le nb de libre sélectionné (par ex : pour éviter une maj de toute les données par erreur humaine))
P.S. : Il s’agissait du cas “Select All”, autrement (sélection normal) nous utilisons la façon de faire suivante : this.getSelectedIds().size();