2009-03-31 4 views
1

Nous avons une base de données existante et fonctionnelle créée à partir de fichiers de mappage hbm.Fichier de mappage d'hibernation avec dépendances aux tables/POJO existants

Nous voulons créer de nouvelles tables pour une fonctionnalité optionnelle.

Une option est que ces nouvelles tables existent toujours mais nous préférerions que les tables et les POJOs ne soient créés que sur demande.

Mon problème est que ces tables/POJOs ont des dépendances sur les tables/POJOs existants. J'ai créé un fichier de mappage mais je ne peux le faire fonctionner que s'il crée des commandes de création/suppression pour les tables existantes et les nouvelles, ainsi que leurs POJO. Puis-je éviter cette table existante/POJO pour Groupe apparaissant dans le script de création.

Dans l'exemple ci-dessous, Group est une table/POJO existante.

<id name="id" type="java.lang.Long"> 
     <column name="ID" not-null="true" /> 
    </id> 

    <many-to-one name="group" 
     class="uk.co.foo.domain.dfwv.Group" 
     foreign-key="GROUP_FK" lazy="false" not-found="ignore"> 
     <meta attribute="use-in-tostring">false</meta> 
     <column name="GROUP_NAME" 
      not-null="true" /> 
    </many-to-one> 
</class> 

L'objectif de fourmi pour générer c'est au-dessous et ne fonctionne que si les objets dépendants sont répertoriés:

  <fileset dir="${dfwv.mappings.dir}"> 
       <include name="**/groups.hbm.xml" /> 
      </fileset> 
     </configuration> 
     <hbmtemplate exporterclass="uk.co.foo.hibernateutils.tools.Exporter" templateprefix="config/foopojo/" template="config/foopojo/Pojo.ftl"> 
      <property key="jdk5" value="true" /> 
      <property key="ejb3" value="false" /> 
     </hbmtemplate> 
    </hibernatetool> 
</target> 

Sans la référence dépendante au groupe puis-je obtenir l'erreur:

BUILD ECHEC C: \ projects \ foo \ db-build.xml: 187: Texte du schéma a échoué: Une association de le DISCON_TEST de table fait référence à une classe unmapped: uk.co.foo.domain.dfwv.Group

Version Hibernate: 3.1.2

Répondre

0

N'a pas pu vous jus t commenter les mappings jusqu'à ce que vous en ayez vraiment besoin? hibernate a besoin d'un méta-modèle complet des entités fournies et ne peut pas créer simplement des "stubs" pour certains d'entre eux

+0

Je pourrais et cela fonctionnerait mais les builds sont créés à partir d'un serveur de build donc je devrais valider ce changement et exécutez la même cible de génération. Pour l'instant, j'ai au moins une cible que le serveur de construction peut exécuter pour la nouvelle fonctionnalité sans avoir à apporter de modifications de code. –

+0

Je suppose qu'avec ces nouvelles entités - mais désactivées - vient la logique métier supplémentaire, gardez-vous cela aussi "désactivé"? cela ne se briserait-il pas aussi, parce que la logique (va un jour) combine des entités anciennes et nouvelles? sonne comme l'enfer maintance ;-) –

Questions connexes