Nous avons un objet de relation NN entre deux objets A et B. Sur cet objet NN nous avons un champ type.
Quand nous affichons A en liste, nous souhaitons avoir deux colonnes B distinctes : une pour les données de type 1, une pour les données de type 2.
Nous avons donc créé deux objets hérités de NN : NN1 avec un filtre type=1 et NN2 avec un filtre type=2.
Chacun de ces objets a deux foreign key vers A et B.
Nous obtenons bien nos deux colonnes en pillbox avec les bonnes valeurs.
Dans la requête exécutée, nous constatons que le filtre appliqué sur la NN ne tient pas compte du champ “filter” de l’objet
and exists (select 1 from rci_accountable_appsub nn, m_index nx where nn.rci_acc_appsub_id = t.row_id and nx.idx_object = 'RciUser' and nx.idx_row_id = nn.rciaccountable_user_id and nx.idx_ukey ilike 'Constance%')
Est-ce que ce type de paramétrage est possible d’une autre façon ? Ou avons nous commis une erreur ?
Question subsidiaire mais n’hésitez pas à me dire s’il faut ouvrir un autre ticket : nous avons remarqué que sur les listes avec Pillbox, il semble y avoir autant de requêtes effectuées que de lignes affichées, ce qui impacte les performances à l’affichage de la liste.
where (t.row_id=2212) → appelé pour chaque row_id semble-t-il
Ce cas de paramétrage me semble assez complexe. Nous n’avons jamais utilisé un héritage de NN dans plusieurs pillboxes en recherche (si j’ai bien compris la question).
La requête générée ne comporte pas le “type” cela veut dire que ce n’est pas l’héritier qui est utilisé pour différencier les 2 liens. Il faudrait voir si Simplicité serait capable d’ajouter la search-spec en plus dans la recherche full-text.
Pourais-tu nous donner le modèle de classe et le paramétrage des liens pour qu’on essaye de reproduire et trouver une solution ?
A défaut, il faudra passer par un hook pour limiter les résultats (pre ou postSearch de l’objet).
Le filtre d’une pillbox en liste est donné par :
Dans l’objet front, il est véhiculé dans l’objet filters de l’instance avec un préfixe “link__” : link__<childObjectNN>__<foreignKeyField>
En back, il est placé dans le Link correspondant de l’objet :
// one link
String filter = getLink("childObjectNN", "foreignKeyField").getFilter();
// all links
for (Link link : getLinks()) {
filter = link.getFilter();
// ...
}
Ok, merci pour ton retour.
On a donc 2 NN de noms différents mais qui pointent sur la même table et la même FK.
Il va falloir une petite évolution pour ajouter la search-spec dans la recherche générée (au soucis prêt de l’alias “nn” vs “t” à résoudre car t est déjà la liste et pas la NN).
En attendant j’ai tenté d’implémenter le filtre dans le preSearch mais j’ai l’impression que ça casse la requête.
Le filtre “socle” apparaît dans la requête finale mais pas dans la searchSpec where exists (select 1 from rci_accountable_appsub nn, m_index nx where nn.rci_acc_appsub_id = t.row_id and nx.idx_object = 'RciUser' and nx.idx_row_id = nn.rciaccountable_user_id and nx.idx_ukey ilike ?)
On dirait qu’une fois que j’ai filtré sur une pillbox cette requête est appelée autant de fois qu’il y a de lignes avec le row_id en “Host= …”.
Et quand je fais un setSearchSpec dans le presearch ce Hosts est effacé ce qui fait qu’on n’a rien dans le paramètre “?”.
C’est possible ?
Pas sûr d’avoir suivi ton raisonnement sans voir le code.
Il y a autant de recherches que de pillboxes : c’est normal car pour chaque ligne il faut aller chercher les NN à afficher en pillbox = toutes les clés fonctionnelles des objet liés.
Pour s’en sortir, il faut que Simplicité ajoute la search-spec du lien dans la sous-requete qui fait la jointure avec m_index. Il va falloir faire un replace “t.” par “nn.” ce qui n’est pas top si la search spec contient du texte genre ‘Simplicité will do it.’
Si tu veux coder des choses : il faut tester si 1 des 2 links à un filtre comme indiqué plus haut, et ajouter une search spec sur un champ (field.setAdditionalSearchSpec) ou globalement (setSearchSpec).
N’y passe pas trop de temps pour trouver un contournement, car on va livrer l’évolution en 5.2+ pour appliquer la search-spec de l’objet NN lors de la recherche en liste avec un filtre sur champ pillbox :
where exists (select 1 from rci_accountable_appsub nn, m_index nx
where nn.rci_acc_appsub_id = t.row_id
and nx.idx_object = 'RciUser'
and nx.idx_row_id = nn.rciaccountable_user_id
and nx.idx_ukey ilike ?
and (... search-spec ...))
Pour information, j’ai aussi un problème dans le cas où une des deux clés de ma NN est une clé virtuelle sans nom physique. Dans ce cas la recherche échoue car la requête fait un NN. = …
Dans tous les cas j’ai pu contourner en vidant ce filtre et en le reconstituant selon mon besoin dans le preSearch()
)