Hibernate Tools et la base de données en constante évolution

Question

J'utilise actuellement Hibernate Tools 3.1; J'ai personnalisé la convention de nommage et les modèles DAO. La base de données (SQL Server 2005) en est au début de la phase de développement et je suis responsable de la reconstruction des mappages, des entités, des DAO, de la configuration, etc. À chaque fois que je dois désosser les tables, je perds toutes les personnalisations que j'ai apportées aux mappages (fichiers * .hbm.xml), comme l'ajustement des colonnes identité et la sélection des champs utilisés dans . est égal à et toString . Je pensais écrire le XML diff dans un fichier et le "fusionner". cela sur le mappage généré (voir ma question connexe ) mais je me demandais ... y at-il meilleur? pratique / outil pour faire face à ces tâches ennuyeuses, inévitables et critiques?

Answer 1

Je recommanderais fortement de ne pas procéder à une ingénierie inverse continue. La rétro-ingénierie est une bonne chose à faire une fois, mais les modifications doivent être gérées comme des modifications à la fois du hbm et de la base de données.

Nous utilisons les migrations pour gérer les modifications de la base de données, et nous incluons les modifications associées dans hbm. Si Hibernate l’a (je crois que oui), vous voudrez peut-être examiner les annotations au lieu d’un hbm, elles peuvent être un peu plus faciles à gérer.

Answer 2

Nous avons deux ans et demi de retard, mais je vais émettre un avis dissident. Vous devriez pouvoir effectuer les personnalisations nécessaires aux fichiers de mappage via le fichier hibernate.reveng.xml ou une ReverseEngineeringStrategy personnalisée. Pour les classes elles-mêmes, vous devez toujours générer des classes de base et les étendre avec des classes contenant du code personnalisé.

Par exemple, générez com.company.vo.generated.CustomerGenerated et étendez-le avec com.company.vo.custom.Customer. La génération de code devrait écraser toutes les classes du paquet généré, mais jamais le paquet personnalisé (bien que vous puissiez faire en sorte que Hibernate Tools génère ces classes personnalisées dans le répertoire cible afin de pouvoir copier et coller des blancs dans le répertoire personnalisé si nécessaire). De cette façon, vous pouvez remplacer les méthodes pour equals, toString, etc. dans les classes personnalisées et ne pas perdre vos modifications lorsque vous régénérez. Notez également que la meilleure pratique consiste à ne pas archiver le code généré dans SCM.

Sur ce site, vous trouverez d’excellents exemples sur la façon de réaliser cela à l’aide de Maven, du plug-in Hibernate3 et du plug-in Build Helper. La plupart d'entre eux ont des réponses très utiles de Pascal Thivent. Cette méthode fonctionne à merveille pour moi et, même s’il ya un peu de courbe d’apprentissage, il est merveilleux de pouvoir propager les modifications de la base de données dans l’application avec une seule commande Maven.