Récupérer la requête SQL d'un export CSV (méthode de la javadoc)

Support
1

Bonjour,

Je travaille actuellement sur une “extraction” de requête SQL.
Il s’agit là de récupérer la requête SQL de l’export CSV fait avec : CSVTool.export(…)
J’aimerais savoir, si possible, comment je pourrais récupérer la requête SQL exacte qui est utilisée pour générer l’export CSV (dans une optique d’adaptation pour nos besoins spécifiques).

Merci d’avance pour votre aide !

Mounir

2

Bonjour,

D’une façon générale on ne peut pas accéder au SQL en mise à jour, on peut tracer les requêtes dans les logs via le paramètre LOG_SQL_USER = yes.

L’export fait en plus d’un search normal (pre/postSearch…), un pre/postExport sur l’objet.

Pour modifier le résultat de l’export, il faut donc agir par paramétrage ou par code :

  • sur les colonnes ramenées en jouant sur la propriété “exportable” des champs
  • sur les lignes, en jouant sur les filtres ou la search-spec de l’instance (preExport) ou sur les lignes ramenées après “select” en base (postExport)

Il est toujours possible de faire un “select” spécifique :

  • via un objet “select” dont la search-spec est une requête complête qui ramène des colonnes dans l’ordre des attributs d’objet (y compris les champs cachés comme le row_id et les timestamps si l’objet en possède)
  • via une publication et une méthode que fait du SQL
1 Like
3

En effet et c’est ce que j’ai premièrement fait.

Cela est effectivement un bon départ pour répondre aux besoins cependant il me faut encore faire de la modification de la requête sortante de l’objet “select”.

Je voulais éviter de retirer les champs cachés, mettre les alias correspondant au traduction (“FRA”) (qui peuvent même être amenés à être modifiés par le futur) et remplacer les 1 et 0 des booléens en Oui et Non respectivement… (à la main)

Le faire une fois ne m’aurais pas déranger, mais dans mon cas il me faut ces requêtes “adaptées” pour plusieurs dizaines de table… ce qui est assez lourd et chronophage.

P.S. : Le besoin est d’avoir une requête SQL permettant d’avoir exactement le rendu de l’export CSV (et ceci pour plusieurs objets)

4

Impossible, vous mélangez accès aux données métier et présentation des données, le SQL n’a jamais été adapté à fournir des données “front” directement sans mise en forme quelque part.

Il n’y a aucune requête SQL qui retournera “Oui” ou “yes” à la place de “1” dans Simplicité, ou une date formattée pour la présentation au choix de l’utilisateur. Le format en back est universel et commun à toutes les interfaces (SQL / java / ajax / API) : une date est au format YYYY-MM-DD H24:MM:SS, un booléen 0/1 (et true/false en json), un code unique d’énuméré et pas sa traduction, etc.

Agir sur la requête de base relèverait de la bidouille avec des “replace” hasardeux et non pérennes.

L’affichage dans un écran ou dans un export (csv/excel/pdf) relève d’une couche de présentation en fonction de la UI et préférences utilisateur (ex : date suisse, timezone geneve, chiffre allemand).

Il convient plutôt de fabriquer des objets métier dédiés à vos exports :

  • même table et certains champs dans un autre ordre (si très distant de l’objet de base)
  • avec des filtres ou du code dédié
  • utiliser de l’héritage pour factoriser ce qui peut l’être (des “replace” génériques dans le postExport en fonction du type des attributs…)

Ensuite laisser les méthodes de présentation faire les transformations.
Pour l’export CSV, historiquement si c’est un profil ADMIN qui exporte, les données sont volontairement non présentées = réimportable au format de la base. Il faut utiliser un profil non admin pour exporter les libellés dans sa langue et ses préférences.

1 Like
5

Merci pour tous ces éléments de réponses très pertinents.

Nous nous contenterons finalement du format classique des requêtes SQL loggable (ce qui fait bien plus sens, en effet, que du “bidouillage” dont je parlais)

Merci encore !

Mounir

6

This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.