7
votes

Générer des fichiers Hibernate HBM XML et des classes d'entités du schéma de DB existant

Comment puis-je générer des classes de fichiers XML Hibernate HBM XML d'un schéma de DB existant?


0 commentaires

4 Réponses :


1
votes

Je recommanderais outil Hibernate


0 commentaires


3
votes

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).


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)

  • De nouvelles tables continueraient à arriver, alors je pourrais les générer de la base de données (en utilisant hibernatetools et produisant des entités annotées) (nous utilisons réellement un autre processus en ce moment ...)
  • 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)!

    • 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!).

      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é.

    • Je voulais aussi migrer mes séries vers des génériques (sauf le réglage que je ne me suis pas dérangé pour le moment).

      Pour la migration de mappage, j'ai utilisé des outils Hibernate (personnalisés selon les besoins, le modèle et le code), comme suit:

      • La source des informations était les fichiers .hbm.xml, avec le fichier hibernate.cfg.xml

        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 ...

      • 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)

        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:

        • change persistance.cfg.xml pour utiliser la classe au lieu de la .hbm.xml
        • couper et coller @entity avant le nom de la classe
        • Coupez et collez tous les champs de jeu après les champs existants, supprimez uniquement les celles existantes qui ont une erreur compilée (le résultat est que j'ai maintenant des champs avec des ensembles génériques)
        • Couper et coller tous les getters (qui est le reste de la classe) après les ensembles existants
        • Ouvrez la vue conttrête, affichant uniquement des méthodes dynamiques publiques qui ne commencent pas par "SET", triés alphabétiquement
        • Vérifiez chaque getter qui n'a pas d'erreur (enquête si quelque chose a mal tourné, sinon elle avait été abandonnée depuis ...)
        • Après la vue des contours, ne tenant compte que des méthodes erronées, pour chaque getter dans l'ordre: Supprimer la deuxième instance de la méthode, copiez ses annotations à la première instance. (Navigation à l'aide de la vue de contour) (l'ordre des méthodes de la classe est préservé, qui a été important pour l'historique des CVS, notamment en prouvant des incroyants que la migration ne cassait pas leur code, c'était déjà brisé avant!).
        • ... quelques détails laissés pour une discussion plus poussée ...

          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! ; -)


1 commentaires

"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é?



0
votes

NetBeans a une fonctionnalité pour générer des fichiers de configuration, des fichiers annotés et plus


0 commentaires