Hi,

I have two tables with a relation one-to-many from CONTINENT to COUNTRY

Here are the tables:

CONTINENT (id_continent, id_language, continent)
COUNTRY (id_country, id_language,id_continent, country)


So, id_language is shared by both the foreign and the primary keys in COUNTRY table

I'd like to use hibernate mapping in this context through a class key containing id_X and id_language properties.

Do you think it's possible?




Thanks
Guillaume

Absolutely. The mapping from continent to country is easy, I presume that it's the reverse mapping you're interested in. So long as you use "formula" elements/attrbiutes in the foreign key when referring to columns that have already been mapped (obviously the id_language column, in your case), then the normal rules apply. You'd get something like this:

Hi,

I am facing a similar challenge with a legacy database (that of course cannot be altered). I have 2 tables that have 2 natural composite keys each and a join table. The 2 tables share one of the composite keys just like the previous posting.

However, instead of a one-to-many relation, we were trying to implement a many-to-many with a join table and were getting the "org.hibernate.MappingException: Repeated column in mapping for collection: ..." error.

After researching the Forum, we tried the workaround in the previous posting (replacing the <column> with the <formula> tag) on the repeated key and this resulted in a NullPointerException.

Oddly enough it worked when we replaced <column> with <formula> on BOTH keys, but this only worked on read operations. When inserting, it tries to put NULL into the other key column.

I have all the details to recreate this. I tried to boil this down to a simple runnable example. Here are the table defs:



Here are the mappings for Table1 and Table2



To save space the classes are not listed. We did make sure they were Serializable and that both Equals and hashCode were implemented correctly.

When running this you get the following stack trace: (please note that the stack trace is from our production code rather than the example above. Everything above buildSessionFactory is the same.)



I have debugged this and found that, if it is a bug, that it involves the elementFormulaTemplates array member of the AbstractCollectionPersister class. The array is initialized in the constructor from a column iterator. I noticed here that all non-formulas are skipped and the value at the corresponding index is left as null in the elementFormulaTemplates array. Later from the getElementColumnNames() method (same class), it calls down into several StringHelper.replace() methods that assume that the template String argument will never be null when it calls template.indexOf().

I realize that 99% of these are actually user error and not bugs in the system. If I'm making a conceptual mistake, could you please steer me in the right direction? If this is a bug that has been addressed then my apologies for missing it in my JIRA search.

We are reshuffling some of our stories in our project to buy us some time in hopes of being able to find a workaround for this. Please let me know if you need any more information. Just wanted to say that Hibernate is a most excellent tool!

Thanks very much for your help in this!

Jerry

Before I think too hard about this one, I've got to ask why you're repeating column "id_b" in the join table mapping. That doesn't look right. At first glance I'd say that you want to refer to just id_a in the bag's key, and use two columns in the many-to-many association.

If there's a genuine need to repeat the id_b column, then my recommendation would be to make the table1 to table2 association inverse, so that you can safely use formula attributes in the many-to-many mapping. This will require that Table2Class objects are created, saved, then added to any Table1Class objects. The mapping above would allow them to be created, added to a Table1Class object, then cascade-saved from there: you'd lose that ability but gain the ability to use the formula attributes, if you map that mapping inverse.

Hi,

Thank you for your response.

I agree that something feels wrong here. The relationship between Table1 and Table2 is straighforward I think. Table1Class holds onto a list of Table2Class items. We only need unidirectional navigation from the Table1Class to the list of Table2Class items. We know there's a one-to-many relationship there, but there is also a many-to-one because a Table2Class item can be shared between different Table1Class objects.

The column is repeated because the column in the join table is shared in two separate foreign keys on both sides of the join. In a situation with surrogate keys, this is a no brainer. You have Table1 with key 'a' and Table2 with key 'b' and the join table would have 2 columns 'a' and 'b'. The composite keys on some of the legacy tables are throwing us for a loop . Here's an example that describes our situation. Table1 has composte key 'a' and 'b' and Table2 has composite key 'c' and 'd'. One would think that the join table would be all 4 columns 'a' thru 'd'. In our case, the join table only has 3 columns because 'b' and 'c' are actually the same natural key.

I've thought about this and tried the mapping changes you suggested (only one column id_a in the key and 2 columns, id_b and id_c in the many-to-many mapping) and we get the following error (please note the stack trace is from the version at work)



Seen this one before. Hibernate requires the number of foreign key columns from the join table (PACK_LINE_CODES) to match the number of primary key columns in Table1 (PACK_COMPLIANCE). I tried this the other way just for grins (2 columns in the key (id_a and id_b) and only one in the many-to-many mapping (id_c) and got a similar error:




Now the number of columns in the foreign key don't match the number of primary keys from Table2 (CARMA_LINE_CODES_V).

I will give some thought about your second suggestion and try out a few things.

Thanks again for your help!

Jerry

Reference documentation has an example mapping, If in case, you havent looked at it.

http://www.hibernate.org/hib_docs/v3/re ... manytomany

As usual, I find things the hard way. I wound up finding the <formula> technique thru forum postings, but that example 23.4.3 is right on.

The only difference is that we wouldn't have the inverse on the "users" set in the mapping for the Group class. For us, there is no set mapping for the "User" class because we only need unidirectional navigation from Group to a list of User items.

I'm wondering if were making any conceptional mistakes there. There's nothing that requires us to make the navigation bidirectional in this case, is there?

Other than that, I don't see any significant difference from the example and what we are trying to do. We are on version 3, but not the latest release. I've been on the JIRA trying to see if this is a recently-fixed bug (because I'm getting management pushback about getting the latest), but I'm about ready to just grab the latest and see if it works.

Thanks for the help, it is much appreciated!