Items de liste non initialisés dans les attributs d'action

[Emmanuelle (Emmanuelle Fenice)]

Request description

Je reprends le point 1/ de ce ticket que vous avez fermé.
Nous sommes bien sur une version à jour 5.3.39.

Les items d’un attribut d’action ObjectFieldList sont initialisés dans le initAction.

ObjectField f = action.getConfirmField(lang, COUNTRY_FIELDNAME);
ObjectField org = action.getConfirmField(lang, ORG_FIELDNAME);
ObjectField orgdom = action.getConfirmField(ORG_DOMNAME_FIELDNAME);
			
ObjectDB sub = getGrant().getTmpObject("RciSubsidiary");
sub.resetFilters();
sub.getField("rciSubScope").setOrder(1);
			
List<String[]> subList = sub.search();
			
f.getList().getItems().clear();
for (int i = 0 ; i < subList.size() ; i++)
{	
	sub.setValues(subList.get(i));
	f.getList().putItem(sub.getRowId(), sub.getFieldValue("rciSubScope"), true);
}

Au premier appel de l’action, mes item de liste sont vides.

Au deuxième appel ils sont renseignés.

C’est le traitement du premier appel qui est effectif au deuxième car si je vide la liste avant de la remplir en ajoutant ceci

f.getList().setItems(new ArrayList<EnumItem>());

elle devient vide à tous les appels.

Dans Network, je regarde la Response et constate qu’il semble mis à jour après le passage dans initAction, même si le popup de confirmation attend la fin du initAction pour s’ouvrir.

Avec un sleep() dans le initAction, je vois que la Response est envoyée à 15:38, heure du passage dans initAction, mais mise à jour en dernier à 15:37 soit avant le passage dans initAction.

List de valeurs au premier appel (vide)

Liste de valeurs au 2ème appel (remplie)

Puisque vous ne reproduisez pas sur la Démo, il doit s’agir d’un problème chez nous mais je ne peux pas aller plus loin car je n’ai pas accès au code qui constitue la Response.
Peut-il s’agir de notre architecture ? Ou d’un paramètre particulier ? D’une lenteur ?

Ce ticket n’est pas urgent car nous avons contourné en production en passant par une liste statique.
Merci.

[Francois (François Genestin)]

Bonjour,

2 pistes :

• Il faudrait debugger ce que ramène réellement ce search au premier appel ? L’objet est il complexe ? search spec, filtre par défaut. …
• Et copier/coller l’exemple de code fourni (sans search juste des codes/valeurs ajoutés en dur) pour voir.

UPDATE et la bonne pratique …

• ajouter un synchronized(sub.getLock()) entre le reserFilters + search. A faire partout où cette instance d’objet est utilisée / concurrence d’accès.

[Emmanuelle (Emmanuelle Fenice)]

Le search ramène bien quelque chose, j’ai 69 lignes au premier appel et bizarrement 70 au second, j’ai en supplément un item vide.

Taille de l’ObjetFieldList
1/ Au premier passage avant putItem
2/ Au premier passage après putItem
3/ Au deuxième passage avant putItem
4/ Au deuxième passage après putItem

Le 70ème élément du 2ème passage

Même souci avec le code de Démo que tu m’as envoyé

1er appel

Response

2ème appel

Response

Nous avons ce souci depuis la 5.3.37 donc il doit s’agir d’une collision entre un paramétrage chez nous et un changement dans le socle. Peut-être au niveau du Field ?

[Francois (François Genestin)]

Etrange,

1. il faudrait créer un champ uniquement dédié (et sans nom physique) à cette action.
   car réutiliser un champs qui doit être utilisé ailleurs ne doit pas être un bonne idée.
   Un attribut d’action est

• soit un champ de l’objet à confirmer en lecture
• soit un champ libre de l’action en écriture qui pointe sur un liste de valeurs propre

2. Vous faites forcement des choses exotiques qq part, un search qui ne ramène pas 2 fois la même réponse avec la même question démontre un pb de concurrence d’accès / synchronized quelque part.

Remplacez ce search par un select direct en base getGrant().query(...), vous éviterez les couches logiques de votre objet, les accès concurrents… ou alors utilisez un instance dédiée autre que tmp.

3. Sur l’exemple, faites le test avec la Demo et sans aucun lien avec votre module pour voir si c’est général ou purement lié à votre paramétrage ou infra.

[Emmanuelle (Emmanuelle Fenice)]

C’est bien un Field qui ne sert qu’à cette action, j’ai retiré le nom physique pour voir mais j’ai toujours le problème.
Le search ramène bien toujours la même chose, c’est le ObjectFieldList qui récupère une ligne vide en plus au 2ème appel.
Est-ce que tu pourrais me donner le paramétrage de ton Field et de la List of values ? C’est peut-être de ce côté là que j’ai une différence.

[Francois (François Genestin)]

C’est un field simple avec une liste simple…

Je pense avoir compris, c’est un problème de cache lorsque le champ n’a jamais été chargé après un clear cache global. En fait ça se produit une seule fois de mon côté. On va forcer de le charger avant d’appeler l’initAction.

En attendant tu peux surement faire pareil par code :

// init the default list
f.loadList(obj, "RCICOUNTRIES", getGrant());
// reset list
f.getList().getItems().clear();
// putItem...

[Emmanuelle (Emmanuelle Fenice)]

Oui c’est ça ça ne se produit qu’au premier appel.
Et c’est bien la cause de notre problème car avec le loadList ça se charge du premier coup.

Merci