Hi everyone,

I'm trying to map the following relations:




That you can translate by:
A has a subset of E
B has a subset of E
C has a subset of E

the index allows to map an entity E with any entity A, B or C identified by ID (A, B & C have the same kind of Identifier) and thanks to the TYPE column (A, B or C)

I believe I should use the something like that for the INDEX



but I've read in the doc, so I wonder if it's really safe to use it?

Now I don't need a collection of <any> type, I need 3 collections of E entity, one for A, for B, for C... I'm wondering how to implement a <map> of E entity for each of these object.


I watched carrefully the forum but exmaples on this are rather slim (or difficult to find out)
Thanks in advance for any hints.

Actually I think I took the problem the other way around.

I always know what kind of entity collection I desire for my A B C entities.

So the question would rather be how could the <key> element of the <map> reference a TYPE and an ID



What could I possibly add to the mapping for it reference only entities with of a certain TYPE?

I could use a <composite -id> but then I would have to map INDEX table.
A simple <many-to-many> should be sufficient to ref the composite key though.

Any advice or thoughs about that?
thanks in advance for any help!

Could someone tell me if discriminator-value could be of any help for my problem or if it is only for subclassing purpose as it looks like?

Sorry guys, I must be really dumb but I can't figure out a solution for my variable one-to-many problem.

I'm stuck and fear to have to implement 3 index tables, one for each A B C, entity which is the only solution available for me now

Any hints would be greatly appreciated!

No it won't help

I'm screening the documentation from beginning to end since i'm really stucked.

So I figured out I cound't get anything from that discriminator stuff!

But thanks anyway for answering!
Coz up to now I'm making questions and answers!!

But still, I don't see any solution coming up.

If I use a <any> I could have an INDEX object containing pairs like (A, E) (B, E) or (C, E) which is not what I want indeed.

I really need a SortedSet of E for each object A, B & C and I end up thinking there's no way to automatize that.
So or I develop some code to build my SortedSet or I create 3 index, INDEX_AE, INDEXBE, INDEX_CE which not nice at all from a PDM point of view but quite simpler from hibernate's one!

Any confirmation of my guesses is still welcome...

give complete table description with pk and fk

You can do something implementing the Lifecycle interface to manually map your needs.

I can sum it up very shortly



Each records in E belongs to A OR B OR C
A, B & C have the same ID strcture so that I can reference ID_A, ID_B_ or ID_C with TYPE (being A or B or C) and ID. I can't settle any FK here though, because it's variable.

To put it simply INDEX allows me to select a subset of E for each A, B and C.

Moreover, it'a unidirectional, I never need to know to what table (A, B or C) a record E is related.


Lifecycle object is definitely an option to consider. Not simple though, I'd have to implement some queries in it which doesn't sound very proper to me.
ON top of that I'm wondering if performance wise CallBacks are OK?
I already use them to replace any attribute with an empty String ("") with a null, that means object is screened before any SAve or Update and I must say I'm a bit afraid of that.

You know, refactoring you DB should be the best option if available