Select(id) d'un objet temporaire retourne false alors que l'id existe

Bonjour,

j’ai un bug dans une ancienne application que je n’arrive pas du tout à comprendre. Pour des besoins d’export, j’ai besoin de récupérer les données d’un objet et je passe par un objet temporaire :

var testId=this.getRowId();
var test =this.getGrant().getTmpObject(“CrbRechDemande”);
test.resetFilters();
if(test.select(testId)){
blablaba
}

dans certains cas, le test.select(testId) retourne false alors que l’id existe bien …
je ne sais plus ou chercher …

Y-a-t-il quelque chose de particulier sur cet objet, ex: une search spec (statique ou dynamique), un row ID custom, etc…

Sinon il n’y a vraiment pas de raison que ça ne marche pas

je fais un resetFilters() donc les searchSpec ne doivent pas empecher le select
en plus, les id en question s’affichent bien dans la liste à l’écran

je soupçonne une donnée car ce n’est que dans certains cas mais je ne vois pas ou chercher

Les filtres et le search spec ça n’a rien a voir.

Le search spec n’est donc pas impacté par un resetFilters.

  • Une search-spec est un morceau de SQL “where” forcé
  • Un filter est un filtre accessible à l’utilisateur.

Regardez dans le load de l’objet ou sa définition.
ajoutez qq chose comme if (this.isTmpInstance()) this.setSearchSpec("1=1");
pour ne pas mettre de search spec pour un usage de cette instance temp.

ps David va faire tes valises ;-)

j’ai ajouté if (this.isTmpInstance()) this.setSearchSpec("1=1") ça ne change rien.

L’utilisateur qui exécute ce code a-t-il les droits de lecture sur l’objet ?

sinon il faut lui ajouter dynamiquement via grant.accessObject ou changeAccess avant le select, et lui retirer ensuite via delAccessObject ou changeAccess. ou alors habiliter l’utilisateur qui exporte à cet objet.

oui il a le droit puisque la consultation en liste et en formulaire fonctionne.

et c’est une vielle appli qui foncitonnait très bien jusqu’ici.

je pense vraiment qu’il s’agit d’un pb de donnée ou d’objet lié.
le select fonctionne pour certaines demandes de la liste. c’est très étrange.

est-ce-qu’il y a un moyen de savoir ce qui est exécuté dans le test.select(testId) ?

En rhino on peut activer les traces SQL en joutant en début de script

console.traceObject(true)

vous verrez alors passer dans les logs le select ... where row_id=? qui ne ramène rien, et le tester unitairement pour savoir quelle jointure ne passe pas.

Il y a peut être des références qui ont été supprimées, liens morts dans la base. Si une foreign-key est obligatoire Simplicité génère un “inner join”, sinon c’est un “outer join”.
Vous pouvez donc temporairement modifier le caractère obligatoire de FK pour voir si cela vient de là.

en début de quel script ?

de votre objet CrbRechDemande

ça plante :

|CrbRechDemande.prepareScript||Erreur évaluation script: sun.org.mozilla.javascript.internal.EcmaError: TypeError: Cannot find function traceObject in object com.simplicite.util.ScriptInterpreterConsole@2ce2849. (#1) in at line number 1

votre version doit dater.
cette fonction existe depuis longtemps, cf javadoc de la classe ScriptInterpreterConsole.
https://www.simplicite.io/resources/3.2/javadoc/com/simplicite/util/ScriptInterpreterConsole.html
console.traceObject(true);

on peut le faire via this.setParameter("LOG_SQL_USER", "yes"); dans le postLoad.
mais cela ne marchera pas forcement si vous êtes sur une version qui ne sait pas le faire.

ou sinon on peut toujours activer les traces globales via param système LOG_SQL_USER=yes (de la V2) mais c’est très lourd en log et en perfs.

si vous suspectez des pb de joinuture, il est préférable de faire des “select where not exists” via un accès SQL pour retrouver les liens morts et les corriger.

c’est ce que j’ai entrepris …

Ok donc je ne vois pas trop ce qu’on peut faire au niveau socle pour vous aider à ce niveau (surtout sur une V3.0 qui n’est plus maintenue).

La question de fond est sur le “inner join” ou “left outer join” au niveau des accès base de données.
Tout passer en jointure externe ne fera pas régresser les FK obligatoires, et permettrait de “voir” les objets ayant des liens mort (champs vides à l’écran). Ce serait moins bloquant pour l’utilisateur qui pourra alors modifier/corriger les liens morts.

C’est du même ordre que d’avoir uniquement des colonnes NULL en base alors que les champs sont obligatoires dans les objets suivant le contexte, ou afficher le “code” de liste de valeurs à la place de son libellé si le code est inconnu…

Il faut que la base reste un espace de stockage indexé et transactionnel avec le moins de règle métier possible.