Referencer (encore) un objet SELECT?

Support
1

Bonjour,
On me demande de créer une vue qui rassemblerait différents objets de notre outil, avec possibilité de créer des liens entre eux (c’est là mon problème).
J’ai fait un objet SELECT, mais je me souviens à l’époque n’avoir pas réussi à le référencer à partir d’un objet persisté.
Avant de chercher une alternative à proposer, vous est-il possible de me confirmer que ce que j’essayais de faire via ce ticket n’est toujours pas faisable?

Merci !
Emmanuelle

2

Quand un utilisateur parle de vue, il parle souvent d’objet métier.

Un objet SELECT n’est pas persistant, c’est un agrégat de données qcq pour visualiser des rapports, pas pour faire des mises à jours ou l’intégrer comme un objet métier au reste du modèle.

Sinon comment créer des foreign-key persistantes vers rien ? Un objet SELECT en mémoire n’a pas de clé fonctionnelle, ni de bijection avec un record unique en base…, Comment gérer les delete cascade ou les lien morts, etc.

Même si le SELECT concerné ramène des row_id uniques qui le relie à un seul record en base, au mieux les jointures seront via des “select de select” très couteuses, au pire Simplicité ou la base n’y comprendra rien.

Bref de mon point de vue, il ne faut pas partir dans ce choix de conception.

Il faut persister ce que fait ce “select” dans un vrai objet métier persistant

  • alimentation par cron et/ou au fil de l’eau depuis les objets qui gèrent les données sources
  • avec un row_id + une clé fonctionnelle compréhensible de l’utilisateur
  • foreign-key classiques / delete cascade, etc.

Par exemple pour un consultant qui facture par CRA :

  • l’utilisateur saisie des charges par jour
  • on veut remonter ses charges consolidées par mois
  • une facture mensuelle référence chaque consolidation

Pour ça, on a besoin d’un objet persistant calculé chaque mois, pas d’un simple SELECT.

3

Tu m’as convaincue, je n’avais pas pensé à la question des Delete cascade.
Pour tenter l’exercice, j’avais réussi à concaténer deux entités avec un row_id unique, mais au refSelect, les champs se populatent mais pas le row_id.

	public void postLoad() {
	    
	    String sql = " select '1' + rci_application.row_id, rci_app_identifier, rci_app_name, 'Application' from rci_application where rci_app_identifier like 'IRN-%' " +
	    				" union select '2' + rci_platform.row_id, rci_ptf_identifier, rci_ptf_name, 'Platform' from rci_platform";
	    
	    setDefaultSearchSpec(sql);
	    
	    super.postLoad();
	    
	}

Je vais proposer de passer par un objet spécifique, il faut donc que j’utilise les hooks ou un batch pour gérer la synchro ? J’ai regardé si les data link ne pouvaient pas m’aider mais j’ai l’impression que c’est pour gérer deux objets absolument identiques entre deux environnements.

4

Oui un DataLink synchronise des données via http entre N applications distantes.

Pour alimenter l’objet métier, il faut connaitre la fraicheur des données nécessaires et la complexité des données sources à transformer :

  • fil de l’eau des mises à jour des données sources, si on a besoin de tout voir tout de suite
  • cron périodique si consolidation à heure(s) fixe(s) ou possibilité d’avoir des données que de la veille…

Le batch est toujours à créer pour recalculer les données à la demande ou via cron, pour rattraper les erreurs, suite à import en masse de données sources, reprise de données lors de la mise en production…

Les mises à jour cascades depuis les hooks (postSave/Delete des données sources vers l’objet) sont à faire si besoin d’alimenter la table au fil de l’eau, mais suivant la quantité de données ou les règles de gestion, c’est pas forcement simple à traiter unitairement.

Bref les contraintes techniques sont à confronter aux besoins utilisateurs pour trouver un compromis.

5

Merci beaucoup pour tes conseils, bonne journée !