Hooks bas niveau pour les requêtes Simplicité

Comme discuté lors du point d’échange avec @david, le but serait d’étudier la possibilité d’intégrer des Hooks bas niveau sur les requêtes Simplicité, dans le but de pouvoir stocker certaines informations non disponibles par défaut.

Bonjour Benoît,

je ne sais pas trop quel est votre use case mais de notre côté nous utilisons aussi quelques fois des instructions SQL d’update court-circuitant les règles définies au niveau du modèle logique. Une feature permettant d’exprimer ces requêtes en utilisant les termes du modèle logique (et non physique) seraient dès lors intéressantes pour nous afin de réduire la dette technique afférente en repositionnant l’implémentation au niveau logique.

Pour la petite histoire, nous utilisons ces requêtes pour appliquer des règles de dé-normalisation de certaines informations structurées en les reportant automatiquement à une maille plus macro (quitte à les dupliquer). Les informations reportées à la maille macro sont évidemment en lecture seule afin de garantir que les règles du modèle métier s’appliquent bien à la maille la plus détaillée. Ces copies concernent des informations très sollicitées en lecture et mises à jour à une fréquence très faible. Elles étaient indispensables avant que les mécanismes d’intégration des pillbox en liste ne soient délivrées. Elles restent aujourd’hui très utiles pour ne pas surcharger le rendu des listes qui les présentent (utiliser des pillbox reste beaucoup plus coûteux en ressources temps et machines). Par ailleurs, l’UX basée sur les pillbox est dégradée vis à vis des possibilités offertes sur des champs persistants (filtres utilisateurs, recherches prédéfinies, etc.).

Si votre besoin est à l’inverse de pouvoir intervenir sur les requêtes générées par le socle (comme le fait le setSearchSpec par exemple), je suis intéressé pour en savoir plus car vous avez peut-être eu une idée qu’on a pas eu :wink:

En fait, si j’ai bien compris, il s’agit ici de traçabilité / auditabilité qui, dans le contexte en question (normalisé et outillé), doit se faire au niveau le “plus bas” i.e. au niveau des requêtes / réponses HTTP Java, donc en amont / aval des traitements socle.

Ah ok merci, nous n’avons pas (encore) ce besoin a priori…