2010-02-04 7 views
1

J'ai un curieux casse-tête avec un mappage relationnel objet, en utilisant Java et Hibernate.Mappage d'héritage Hibernate inhabituel

Nous avons un schéma existant qui ressemble à ceci:

create table foo (id int8, /* ... */ primary key (id)); 
create table bar (id int8, foo int8, /* ... */ primary key (id)); 
alter table bar add constraint fk_foobar foreign key (foo) references foo; 

Normalement, vous mapper ce en utilisant une relation ManyToOne.

class Foo { /* ... */ } 
class Bar { private Foo foo; /* ... */ } 

Mais l'un des gars de mon équipe veut mapper ce dans une relation d'héritage:

class Foo { /* ... */ } 
class Bar extends Foo { /* ... */ } 

Est-il possible de retirer ceci avec Hibernate?

Edit: Le point important est que la table bar dispose d'une clé étrangère foo, qui est distincte de la colonne d » identité bar.

+0

J'utilise NHibernate (port de mise en veille prolongée) avec C# et la réponse est oui. Il y a des exemples dans les docs de NHibernate et je suis sûr que la même chose existe pour Hibernate – David

+0

avez-vous résolu votre problème? s'il vous plaît fournir des commentaires. – Bozho

+0

Je suis assez sûr que la réponse est non. Je parie que Hibernate est câblé de sorte que si vous avez une relation d'héritage, la clé primaire dans la table de la classe dérivée doit être une clé étrangère à la table de la classe de base. – leedm777

Répondre

0

Vous ne devez mapper ce comme une relation d'héritage, si la barre est un Foo. Sinon, vous devez utiliser la composition. Mais, bien sûr, je ne connais pas le contexte, donc je ne sais pas si le mappage de ces classes en tant que classe sub et base est correct.

Quoi qu'il en soit, oui, il est possible de le faire. Vérifier the different possibilities to create an inheritance relationship in Hibernate.

Par exemple, vous pouvez utiliser le scénario sous-catégorie A rejoint ici:

<class name="Foo" table="Foos"> 
    <joined-subclass="Bar" table="Bars"> 
    </joined-subclass> 
</class> 
+0

Le cas d'utilisation réel est en quelque sorte une zone grise. La barre fournit des données supplémentaires sur Foo. De cette façon, vous pouvez y penser comme Bar is-a Foo. Mais il peut y avoir plusieurs objets fournissant des données supplémentaires sur le même Foo. Cela penche plus vers Bar a-un Foo. Le mappage que vous fournissez ne correspond pas au schéma existant. La table à barres possède une colonne id distincte de la colonne de clé étrangère foo. – leedm777

+2

C'est une composition pour moi parce que c'est un-à-plusieurs. Vous ne pouvez pas avoir plusieurs barres pour le même Foo en utilisant l'héritage. Pensez au mappage d'héritage pour tous les objets "Informations supplémentaires". – zoidbeck

0
@Inheritance(strategy=InheritanceType.TABLE_PER_CLASS) 
public class Foo { .. } 

Mais le faire que si elle est logique pour être l'héritage. C'est à dire. si elle est Dog extends Animal, et non pas dans le cas où il est User extends Group