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.  [ 1 post ] 
Author Message
 Post subject: subclassing with DiscriminatorValue and DiscriminatorFormula
PostPosted: Mon Dec 27, 2010 12:35 pm 
Newbie

Joined: Mon Dec 27, 2010 12:07 pm
Posts: 1
I have a thread going on the redhat customer portal... but, I don't seem to be getting very far. Maybe someone here could give me a ya [or nay] on this. My thinking right now is this ISN'T possible.

I have a class A. It maps to table X.
I have another class B. It also maps to table X plus it contains a set from table Y.
And, another class C. It also maps to table X plus it contains a set from table Z.

Currently classes A, B, and C all have duplicate properties that map to the columns in table X. Works fine, but, I'd like to use class A as a super class for classes B and C. And, also use A [or another subclass of A] as an entity for simple table X access. Sounds simple... but, I've looped back on trying to figure this out for 2 years now. Time to put it to bed.

The first suggestion from the redhat support was to simply use the DiscriminatorFormula. Problem is classes B and C are "artificially distinct" from class A. Let me state the problem in another way.

In the real application database there are many many inter relationships. For some entities mapping ALL one-to-one, one-to-many, many-to-one joins would be impossible. Therefore, I've defined a very finite/useful subset of similar entities for each table mapping. The 'base entity' is nothing more than a direct mapping of a single table. The other 'alternate entities' are nothing more than 1-N additional one-to-one, one-to-many, many-to-one joins with the 'base entity'... in most cases joined by the 'base entity' primary key. So the distinction between 'alternate entity B' and 'alternate entity C' is simply due to the fact that I chose to include <Set>Y in one and <Set>Z in the other. So...

(select 1 from Y y where y.b_aId = aId) = 1
(select 1 from Z z where z.c_aId = aId) = 1

... are both true in all cases and would not make B distinct from C. Clear, I hope?

If you think this simply isn't possible a simple "yep, you painted yourself into a corner" will do. But, if you have a suggestion... I'd gratefully appreciate an example of the annotations needed to perform this miracle. Thanks!


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

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.