Comment puis-je générer des classes de fichiers XML Hibernate HBM XML d'un schéma de DB existant? p>
4 Réponses :
Vous devez utiliser les outils d'ingénierie inverse hibernate pour cela. Voir le Documentation sur les outils d'ingénierie inverse de Hibernate a > Pour plus d'informations. P>
Ce n'est pas clair pour moi comment générer des classes annotées JPA, mais vous voudrez peut-être penser à n'utiliser plus les fichiers HBM.XML s'il s'agit d'un nouveau projet, en favorisant des annotations. P>
Votre lien semble être brisé. J'ai trouvé un lien qui pourrait être pertinent mais je ne suis pas sûr lequel serait le meilleur. Seriez-vous capable de le retrouver et de réparer le lien brisé? Merci
J'ai utilisé des outils Hibernate (exemples donnés sur leur site) avec beaucoup de plaisir. Ci-dessous, je donne des détails sur mon cas d'utilisation spécifique, avancé et intéressant (je pense). P>
En réalité, je faisais face à un défi intéressant sur notre gros projet (approchant de 800 tables, équipe pilotée de la base de données) p>
Mais la plupart des tables n'étaient pas nouvelles, j'ai déjà eu les implémentations Java et le .hbm.xml.
Les deux avaient parfois été modifiés de la DB qu'ils ont été générés à l'origine avec, il était donc impossible de les ré-générer avec la garantie de ne rien briser. J'ai besoin de migrer les entités, de changer le moins possible (c'est-à-dire que les annotations)! strong> p>
Cela devait être rapide aussi, car nos vieilles entités typiques ont environ 100 membres (propres colonnes DB, plus des collections d'entité provenant de clés étrangères inverse!). p>
Remarque: Deux entités n'ont pas pu compiler avec un constructeur complet généré, ils ont cassé la limite de 256 paramètres! Mais ce que ce constructeur était inutile de toute façon, qui pourrait se souvenir de l'ordre de 256 paramètres, donc je l'ai supprimé. P> Li>
Pour la migration de mappage, j'ai utilisé des outils Hibernate (personnalisés selon les besoins, le modèle et le code), comme suit: p>
La source des informations était les fichiers .hbm.xml, avec le fichier hibernate.cfg.xml p>
Remarque: je devais d'abord extraire l'hibernate.cfg.xml, en remplaçant le haricot de ressort qui contenait la liste. Mais ceci a également été utile pour les outils de base de données tels que l'écureuil, qui pourrait l'utiliser pour activer l'achèvement de HQL ... P> LI>
La sortie générée était x2.java (pour la classe X.java, dans le même package) contenant uniquement les champs, les getters et les annotations
(Pas de setters ou de constructeurs) (ensembles génériques) p> li>
ul>
J'utiliserais le compilateur Eclipse (erreur "Duplicate ...") Pour vérifier mon édition, pour le rendre plus rapide et moins d'erreur (erreur n'était pas une option, nous avons de nombreux clients dans la production!). Pour chaque classe migrée, je copierais de la classe existante: p>
Pour le curieux, ce mois-ci, nous sommes proches de 200 entités annotées :-).
Une entité typique de 100 champs nécessite environ 30 minutes de travail pour migrer.
Il ne reste que 300 heures pour terminer cette pâte CUT'N pour les 600 entités restantes! ; -) p>
"Remarque: deux entités ne pouvaient pas compiler avec un constructeur complet généré, ils ont cassé la limite de 256 paramètres! Mais ce constructeur était inutile de toute façon, qui pourrait se souvenir de l'ordre de 256 paramètres, donc je l'ai supprimé." - COMMENT?? Vous venez de la supprimer post-build? Savez-vous comment spécifier dans un HBM qu'un constructeur complet ne doit pas être généré?
NetBeans a une fonctionnalité pour générer des fichiers de configuration, des fichiers annotés et plus p>