Discussion :

[Nertios]

Bonjour,

Une refonte de la base de données de mon application est prévue. Aujourd'hui, ma bdd contient des tables pour chaque entité de l'application. A l'avenir, un certains nombres de données de références gérées par d'autres applis seront disponibles via des vues sur un schéma différent.

Par exemple, mon appli gère une entité Site liée à une entité Département. Site est mappée sur une table dans le schéma de mon appli, Département est mappée sur une vue dans le schéma référentiel.

Mon problème est que SQL ne permet pas de créer une contrainte de clé étrangère qui référence une colonne d'une vue. Du coup, à la persistance d'une entité, il n'y a pas de mécanisme pour vérifier l'intégrité des données au niveau de la bdd.

Mon idée est donc de faire cette vérification programmatiquement : à chaque création/màj, appeler une méthode qui va vérifier qu'une entité du référentiel existe bien.

Est-ce qu'Hibernate propose un mécanisme permettant de faire ça ?

Cordialement.

[DevServlet]

Bonjour, peut on savoir sur quel SGBD vous travaillez? une vue en soit est une table d'un point de vue JPA, tu peux donc très bien mapper une entité JPA sur une vue, sauf que là tu as un second problème qui se pose, tes vues ne sont visiblement pas dans le même schéma que tes tables principales, dans ce cas si tu es sous Oracle, tu peux créer la notion "Synonyme Oracle" ce qui donne l'avantage d'avoir l'impression de travailler dans un seul schéma. et donc dans ton mapping tu mettras la contrainte de non nullité lors de tes jointures

[Nertios]

Suite à cette refonte, on sera sur Oracle 11.2.

Effectivement, les vues sont dans des schémas séparés de celui des tables. Mais ce n'est pas ça qui me pose problème, ni les contraintes de non nullité.

Ce que je veux, c'est simuler les FK que je ne peux pas créer en SQL. Pour reprendre mon ex. du premier post :
Au niveau de ma bdd, j'ai une table SITE avec une colonne DEPARTEMENT_ID qui doit contenir les données d'une vue V_DEPARTEMENT.
Au niveau Hibernate, j'ai une entité Site qui possède un attribut de type Departement.
Maintenant, je souhaiterais que dès qu'Hibernate effectue une opération de création ou de màj d'une entité Site, il appelle une méthode spécifique qui vérifierais que la vue V_DEPARTEMENT contient bien le Departement lié au Site.

[DevServlet]

Suite à cette refonte, on sera sur Oracle 11.2.

Effectivement, les vues sont dans des schémas séparés de celui des tables. Mais ce n'est pas ça qui me pose problème, ni les contraintes de non nullité.

Ce que je veux, c'est simuler les FK que je ne peux pas créer en SQL. Pour reprendre mon ex. du premier post :
Au niveau de ma bdd, j'ai une table SITE avec une colonne DEPARTEMENT_ID qui doit contenir les données d'une vue V_DEPARTEMENT.
Au niveau Hibernate, j'ai une entité Site qui possède un attribut de type Departement.
Maintenant, je souhaiterais que dès qu'Hibernate effectue une opération de création ou de màj d'une entité Site, il appelle une méthode spécifique qui vérifierais que la vue V_DEPARTEMENT contient bien le Departement lié au Site.

J'ai bien compris ton besoin, tu peux le faire programmatiquement, c'est à dire qu'avant d'effectuer ta mise à jour ou ta création de Site tu fasses un findById de l'identifiant du département que tu veux associer au Site (en cours de creation/modification) , et ce resultat te retourne null tu lèves une exception. Ou tu passes par une méthode listener sur une entité (méthode call back), dans laquelle tu décris l'action à faire en cas de création/modification d'un Site.Lien pour les listeners jpa

[Nertios]

Ou tu passes par une méthode listener sur une entité (méthode call back), dans laquelle tu décris l'action à faire en cas de création/modification d'un Site.

Ca m'a l'air de correspondre à ce que je recherche. Merci.

[DevServlet]

Ca m'a l'air de correspondre à ce que je recherche. Merci.

Si tu préfères, mais perso je ne suis pas fan de ces méthodés call back, pour la raison qu'elles ne sont pas très maintenables,c'est facile d'oublier qu'elles existent lors d'une évolution. Il faut remonter jusqu'au code des entités pour s'apercevoir qu'elles existent, or on s'arrête souvent qu'au niveau des services lors d'une revue de code ou d'une recherche de bug, mais ça te convient, eh ben tant mieux.