Discussion :

[Mister Nono]

Bonjour,

Une application utilise Hibernate pour gérer les tables ORACLE.

Une des tables contient un champ qui est une relation avec une table ORACLE non gérée par Hibernate car extérieure à l'application. Comment dire à Hibernate de vérifier cette relation de type OneToOne ?

Merci d'avance pour vos réponses.

A+

[tchize_]

Tu veux dire que ce champ est une clé étrangère vers cette autre table non gérée?

Au mieux tu peux lui attribuer un champ, qui sera une simple valeur numérique sans signification pour ton application.

Mais franchement mieux vaudrait ajouter cette autre table à ton modèle hibernate pour gérer correctement la relation.

[Mister Nono]

Tu veux dire que ce champ est une clé étrangère vers cette autre table non gérée?

Au mieux tu peux lui attribuer un champ, qui sera une simple valeur numérique sans signification pour ton application.

Mais franchement mieux vaudrait ajouter cette autre table à ton modèle hibernate pour gérer correctement la relation.

Pour ajouter cette autre table au modèle Hibernate je ne veux pas devoir créer l'objet POJO correspondant. Est-il possible qu'Hibernate fasse de l'introspection (refactoring) pour connaitre la structure de la table externe à l'application ?

Merci encore pour ta réponse.

A+

[tchize_]

ca n'as pas vraiment de sens, quel est le soucis à créer ce pojo, ça prendre 10 minutes à faire

[Mister Nono]

ca n'as pas vraiment de sens, quel est le soucis à créer ce pojo, ça prendre 10 minutes à faire

Non car la table contient des dizaines et des dizaines de champs : je sais c'est pas bien mais ce n'est pas mois qui a implémenté cette table pourrie.

Alors ?

[OButterlin]

Comment dire à Hibernate de vérifier cette relation de type OneToOne ?

Que veux tu dire par "vérifier" ?
De quel type est la propriété dans ton entity "géré" ?

[Mister Nono]

Que veux tu dire par "vérifier" ?
De quel type est la propriété dans ton entity "géré" ?

Et bien au lieu de créer le POJO correspondant à cette IMMENSE table (surtout qu'il y en a d'autres à relier), je voudrait qu'Hibernate lise la structure de la table et crée le POJO lui-même.

A+

[OButterlin]

je voudrait qu'Hibernate lise la structure de la table et crée le POJO lui-même.

Oups...
Éventuellement, tu pourrais utiliser une Map<String, Object> ?
(La première partie serait le nom de la colonne, la deuxième la valeur)

[tchize_]

Non car la table contient des dizaines et des dizaines de champs : je sais c'est pas bien mais ce n'est pas mois qui a implémenté cette table pourrie.

Alors ?

Alors, si tu n'utilise cette table que en read-only, tu n'es pas obligé de mapper tous les champs, juste la clé primaire et éventuellement un ou deux champs texte te permettant de visualiser cet objet

[Mister Nono]

Alors, si tu n'utilise cette table que en read-only, tu n'es pas obligé de mapper tous les champs, juste la clé primaire et éventuellement un ou deux champs texte te permettant de visualiser cet objet

Merci beaucoup pour cette première information encourageante.

Comment dire à Hibernate que la table en question est en read-only car il faut surtout pas qu'elle soit effacée quand j'active l'option :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
<property name="hibernate.hbm2ddl.auto">create</property>

Merci encore pour ton avis sur ce dernier point.

Au fait : +1

A+

[OButterlin]

Personnellement, j'utiliserais un "UserType", c'est fait pour traiter les cas non traités par Hibernate.
Je l'avais utiliser pour un champ mot de passe MD5, mais tu pourrais très bien l'utiliser avec une connexion vers une autre base de données.
En fait, tu fais ce que tu veux avec...
L'idée de la Map<String, Object> était là pour palier au fait que tu ne peux pas facilement compiler une classe...

Bref, à toi de voir

[tchize_]

Merci beaucoup pour cette première information encourageante.

Comment dire à Hibernate que la table en question est en read-only car il faut surtout pas qu'elle soit effacée quand j'active l'option :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
<property name="hibernate.hbm2ddl.auto">create</property>

Le create ne fait jamais de drop ou de delete => ce n'est pas un problème.

Pour le reste la notion de read only, faut juste que ton programme ne fasse jamais de save ou de update avec cette entité. Tu pourrais aussi bêtement t'arranger pour que ton utilisateur opérationnel n'aie pas les droits d'écriture sur cette table

Le champ custom est une option, mais tu aura toujours un problème: comment connaitre la liste des valeur possible vu que c'est une clé étrangère? :-)

[OButterlin]

Pour une colonne readonly, tu peux positionner les attributs insertable=false updatable=false

[OButterlin]

Le champ custom est une option, mais tu aura toujours un problème: comment connaitre la liste des valeur possible vu que c'est une clé étrangère? :-)

Dans la méthode nullSafeGet, le paramètre owner représente l'entity concernée, si elle contient les champs nécessaires, l'opération est triviale, sinon, ça va se compliquer

[Mister Nono]

Le create ne fait jamais de drop ou de delete => ce n'est pas un problème.

Je suis désolé mais quand je veux réinitialiser la base de données, j'active ce paramètre qui reconstruit toutes les tables (et donc les vide). C'est cela que je dois éviter par ailleurs avec les tables sur lesquelles il n'y as juste qu'une relation (tables en read-only).

A+

[tchize_]

Ha oui tiens dans mes souvenirs ça ne droppait pas, j'ai du utiliser ça à la seule époqueo où c'était buggué et il manquait les drop

Personellement, je ne suis pas fan de ce switch donc je ne peux vraiment pas t'aider là dedans. Je préfère lancer les DDL à la main, je déteste quand une application a les moyen de le faire d'elle même. C'est le meilleur moyen de perdre une base en production suite à une erreur de config