Les champs calculés non persistés ne sont pas calculés dans les tableaux croisés

Feature request
,
1

Bonsoir,

Version=4.0.P25
BuiltOn=2021-01-12 11:05 (revision 9e3cd7e8f770232676666e662073e6b71e73ee67)

Les champs calculés non persistés semblent ne pas être calculés dans les tableaux croisés.
L’affichage en liste ou formulaire ne pose pas de problème (la valeur calculée est bien restituée).

2

Bonjour,

Le tableau croisé utilise des méthodes de groupement de la base de données (ex : sum, avg, min, max…), et/ou fait des calculs en Java pour les fonctions annexes (ex : moyenne géométrique).

Il doit donc y avoir une limitation pour les champs non persistants (le searchCrosstab doit retourner null ou 0 sur ces champs).

  • Comment est paramétré votre calcul du champ : dans une expression ou dans un postSearch ?
  • Quelle méthode d’agrégation dans le TC ?

A priori, on devrait pouvoir faire en sorte que les champs calculés passent par les fonctions de groupement en Java (et non via la SGBD sum/groupby) sachant que ce sera un peu plus lent (boucle / pas de group by pour lire les champs de chaque ligne).

3

Le groupement en CT a été rendu possible pour les champs calculés en Java en V5 et backporté en V4. Il faudra voir si dans votre cas cela fonctionne au prochain build. Ca devrait même fonctionner pour un champs calculée en axe de ligne ou colonne.

Attention
Le groupement dans ce cas est fait en Java et non en base de données, donc il peut y avoir de grosse différence de performances suivant la volumétrie des lignes à sommer. Il faudra privilégier la persistance de vos champs calculés si la volumétrie à monter en mémoire de la JVM devient trop importante.

Par exemple :

  • Avec un champ persistant : si on a 1 million de lignes en base, un
    select status, sum(amount) from invoice group by status
    ramènera quelques lignes agrégées
  • Mais si non persistant : si le montant est calculé, il y a aura 1 million de lignes en mémoire issues du search normal (pour évaluer les champs calculés au postSearch) avant d’être agrégées par code Java

Une autre approche sera d’avoir la possibilité de faire des champs calculés via des expressions de la base de données, pour éviter les expressions interprétées Rhino ou Java. Là on pourra surement revenir à des expressions SQL avec group-by.

4

Bonjour François,
merci beaucoup pour ton retour rapide.

La configuration des champs concernés est en expression calculée au niveau des Fields.
J’ai essayé de déplacer les instructions de calcul dans le postSelect (mais pas le postSearch).
Le postSearch permet en effet d’insérer cette information de manière très ciblée (en fonction de l’instance) -> ça fonctionne déjà très bien.

Je vais explorer les nouvelles possibilités apportées par le backport/groupby que tu mentionnes.