-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 6 posts ] 
Author Message
 Post subject: table per subclass with discriminator?
PostPosted: Tue Jan 23, 2007 12:33 pm 
Newbie

Joined: Tue Jan 23, 2007 12:07 pm
Posts: 4
Hi,

We have the following domain model:

Class A (Base class)
- has a primary key (PK_A), has a discriminator column (DIS_A)
- has its own table

Class B extends A
- has a primary key (PK_B), has a foreign_key column to class A (PK_A), has a discriminator column (DIS_B)
- has its own table
- can be identified by the discriminator value in class A (DIS_A)

Class C extends B
- has a primary key (PK_C), has a foreign_key column to class B (PK_B)
- has its own table
- can be identified by the discriminator value in class B (DIS_B)

Class D extends B
- has a primary key (PK_D), has a foreign_key column to class B (PK_B)
- has its own table
- can be identified by the discriminator value in class B (DIS_B)

We couldn't find a way to describe the above inheritance using hibernate.

Our model will fall under the 'table per subclass' mapping strategy but it doesn't support discriminator.

The 'table per class' strategy allows us to define only one discriminator and doesn't support second discriminator as well as expects only one table!

Can someone give some hints on how we can map the above described domain model?

Thanks,
Hari


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jan 29, 2007 5:29 pm 
Beginner
Beginner

Joined: Tue Jun 28, 2005 2:43 pm
Posts: 29
Location: Silicon Valley
Are you able to change the schema at all? Specifically, can you combine the discriminators in A and B into a single discriminator (perhaps as A.B)? If so, you can use the 'table per subclass, with a discriminator' pattern. Something like:

<class name="A">
<id ... > ... </id>
<discriminator ... > ... </discriminator>

(A's properties)

<subclass name="B">
<join table="B">
<key ... > ... </key>

(B's properties)
</join>

<subclass name="C">
<join table="C">
<key ... > ... </key>

(C's properties)

</join>
</subclass>

<subclass name="D">
<join table="D">
<key ... > ... </key>

(D's properties)

</join>
</subclass>
</subclass>
</class>

Now an instance of A is mapped only to A, B is mapped to A join B, C to A join B join C, and D to A join B join D.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jan 29, 2007 6:20 pm 
Newbie

Joined: Tue Jan 23, 2007 12:07 pm
Posts: 4
Hi,

Thanks for the reply. It was one of the ideas we have discussed.

As the hierarchy continues further and doesn't stop at D its very difficult to change the domain model. We have some more discriminators going from D, but in a similar fashion.

How can I rate the reply as "Useful", I see only one option solved yes/no!!

Regards,
Hari


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jan 29, 2007 7:36 pm 
Beginner
Beginner

Joined: Tue Jun 28, 2005 2:43 pm
Posts: 29
Location: Silicon Valley
Is it possible that this isn't really inheritance at all, but just a series of (possibly one-to-one) associations? One reason I ask is that I notice B has both its own pk (PK_B) and a separate fk to A (PK_A). Even outside of Hibernate, whenever I've mapped a B as inheriting from A, I've ended up with a single column being both the pk of B and the fk to A -- that way, a single object id is used consistently across all the tables used to persist a single object. If you've built the schema with B having its own identity, maybe you're thinking of them as separate objects, even if you didn't think so. And if you map them as separate, associated objects, you have a lot more control over exactly what the schema looks like, without the constraints of inheritance. Just a thought.

And by the way, thanks for seeking to give me partial credit, but in the end it's no big deal, at least not to me. Used to be people helped each other on the boards without having to make it mercenary :-).


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jan 30, 2007 7:41 am 
Newbie

Joined: Tue Jan 23, 2007 12:07 pm
Posts: 4
The relationships are in UML sense a "is a" relationship. The domain model is a legacy system and we have 100's of tables and to make the join's efficient the discriminator were added.

We are also thinking of keeping the relationship as associations but we will loose the advantage of inheritance in many cases.

I agree with you on the rating comment in hibernate forums...not sure why the G'men did it like that. I would have appreciated a free hand with the posting/response.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jan 30, 2007 7:42 am 
Newbie

Joined: Tue Jan 23, 2007 12:07 pm
Posts: 4
The relationships are in UML sense a "is a" relationship. The domain model is a legacy system and we have 100's of tables and to make the join's efficient the discriminator were added.

We are also thinking of keeping the relationship as associations but we will loose the advantage of inheritance in many cases.

I agree with you on the rating comment in hibernate forums...not sure why the G'men did it like that. I would have appreciated a free hand with the posting/response.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 6 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.