Hibernate Version: 3.0

We have three persistent classes, P1, P2, and Description. P1 and P2 both have a collection of Description entities. This setup works fine if we define our mappings like this:





Note that in P1's description collection, the key column is P1id, and in P2's collection the key column is P2id. The 'description' table hibernate creates looks like this:



This setup works properly with Hibernate.

But in some cases we may have P3, P4, P5, and P6 similar to P1 and P2. In this situation, if we used the approach above, the Description table would have p1id, p2id, p3id, p4id, p5id, and p6id. From a database perspective, we would rather define the Description table like this:



So that the ID of any P entity (1-6) would go in the 'pid' column. The 'ptype' column would contain, ie, "p1", "p2", "p3" etc... In other words, we would store in the table the type and id of the P entity related to this description.

Is there any way in hibernate to mimic this sort of setup?

Thanks!

i cant follow why you want type (called discriminator) both on the table and the foreign key references.

but anyhow, if its for looking up different types from the same id (and those types are not mapped in a hiearchy) you could look at the <any> reference hibernate supports.


if its just to be redundant then you could probably easily manage this by writing a usertype that in addition to the foreignkey wrote the type.

The trouble is that if we have just one "pid" foreign key in the Description table, then hibernate has no way to know which type of P object this description is associated with. We might have a P1, a P3, and a P6 all with the ID 27. If Description.pid = 27, how do we know which of the three it belongs to? In order to solve this, I only see two approaches:

Use a different foreign key field for each type of P (this works)
Use a "discriminator" column of some type to tell us which P type we're related to (we can't find a way to do it like this in hibernate)

We will look at the <any> concept and see if that solves it for us. Here's hoping :)

Thanks,

Geoff

ah - i had it turned upside down (P1 and P2 are really baad example names)

yes <any> is what you want.

We now have it sort of half-way working. We use this mapping in Description:



If we leave it just like this, and we insert a Description directly, it seems to work right. Hibernate creates an entityType column and an entityId column and it sets entityType properly based on the "entity" property in the Description object.

We have two problems still though.

First, it uses the fully qualified object name in the entityType column instead of "P1" and "P2." My understanding was that our <meta-value> elements should have taken care of that.

Also, each P1 and P2 is associated with many descriptions. We add <map> elements to these classes to make these collections work:



When we add the <map> collection, Hibernate adds foreign key constraints to the Description table so that description.entityId has to match an id in both P1 and P2 so we get foreign key constraint violations. If it matters, we're really trying to get it so that we can persist a P1 or P2 and have this cascaded to the contained descriptions automatically. In other words, the P1 and P2 objects "own" their descriptions.

Any more guidance would be great!

Geoff

Ok, things seem to be working now. To get our discriminator columns to use our <meta-value>'s properly, we added "meta-type='string'" to the <any> element. This makes sense.

Also, and this time we're just guessing wildly, we fixed our foreign-key constraint problem by modifying our <map> sections thusly:



The only change is the addition of "foreign-key='none'" to the <key> element. I have no idea if "none" is actually an appropriate value, but it did cause Hibernate to stop creating foreign key constraints on the entityId column.

Did this work because there is no column called "none" or because Hibernate actually recognizes "none" as a special case in the foreign-key attribute? We could find no documentation on the foreign-key attribute with respect to the <key> element.

Geoff

yes - none is actually a newly added still not documented "disable foreign key" creation feature ,)

i would appreciate if you poste a jira about this "hibernate making a foreign key which actually isn't correct because of an <any>" to the JIRA.

Maybe it will be turned down by a "use foreign-key='none'" but maybe we can do someting to deduce that foreignkey constraint is "wrong"