Objet lié avec remote objet

Support
1

Bonjour,

est-il possible de faire un lien entre un objet et un remote objet ?
je m’explique :
en V3, tous nos modules étaient sur la même instance. On pouvait donc très facilement lier les objets d’un module avec un objet d’un autre module.
en V4, nous avons maintenant une instance par module. du coup, comment faire pour lier des objets de 2 modules différents ?

Un cas concret :
Notre module de gestion des campagnes permet de gérer les ouvertures et fermetures pour toutes les applications. Quand on veut qu’une demande d’un dispositif référence une des campagnes ouvertes, on a besoin de lier les objets.

2

Pour “relier” des objets service (ex: les objets rempote Simplicité) il faut utiliser un lien de type metaobjet (= attribut de type “Objet”)

3

merci, c’est exactement ca.

4

par conrte en base de données, dans la colonne metaobjet, j’ai la valeur suivante :
‘CrbEqlRemoteGdParam:14’

difficile à exploiter pour faire des requêtes.

5

C’est le principe des valeurs des liens metaobjet (<nom logique de l'objet métier référencé>:<row ID>). Ce n’est pas un lien “physique” au sens relationnel, c’est une référence polymorphe (y compris entre records d’objets pas situés physiquement au même endroit) qui n’est effectivement pas très SQL-friendly.

Par contre je ne comprends pas pourquoi vous voulez faire du SQL ici alors que vos objets ne sont pas physiquement dans la même base de données.

6

par-ce-qu’on récupère les données dans un décisionnel et qu’on fait des jointures pour répondre à des besoins de suivi par campagne par exemple

7

Alors dans ce cas quand c’est quand vous importez vos données multi-sources dans votre décisionnel que vous devez reconstruire les liens relationnels.

Une référence polymorphe comme ça ne sera jamais exploitable en SQL car la valeur désigne (ici indirectement) la table qui contient le record référencé, or le SQL ne sait pas faire un select from (select nom_de_la_table from ...) where ....

8

Simplicité stocke effectivement l’adresse de l’objet remote (objet et id) et non ses valeurs. Charge au consommateur d’aller rechercher les informations “fraiches” du remote object à chaque lecture, un info-centre doit donc ré-interpréter le remote object avec les données stables (nom de l’object + row_id dans l’autre base).

  • Si vous voulez les avoir en base locale pour les utiliser souvent, il faudra nécessairement les recopier lors de la sélection (avec les pb de resynchro associés donc à limiter à des données stables comme une clé fonctionnelle)

  • ou utiliser un mécanisme plus bas niveau (lien JDBC ou autre) entre les bases et permettre des requetes multi-schémas par code en exposant la base distance comme un schémas local.

    select... from datasource1.table1 a, datasource2.table2 b where a.code = b.code

(J’ai déjà pratiqué ce sport avec Oracle via des DBLINK et les performances étaient exécrables)

9

Avec les vrais objet remote la solution 2) ou quand les bases ne sont pas technologiquement homogènes n’est pas envisageable. Perso j’ai déjà utilisé ce genre de mécanismes avec PostgreSQL c’était vraiment pas idéal (ni en termes de perf ni en termes de maintenance).