There are legitimate situations when I want to use idbag in a join table for many-to-many associations with attributes. In other words, I want to create a new surrogate id in the join table of many-to-many associations with attributes. This is not directly documented in Hibernate documentation and even in the popular books about Hibernate (see references below).

Justification:

All classes are mapped as entity, not components.

I can have class-a associated with class-b through a many-to-many join table with attributes encapsulated by class-c. Here is the diagram for that.

class-a 1<---->*class-c*<---->1 class-b

In this case, we know that the id for class-c is a composite-id of the id of both class-a, class-b. I mapped all classes as entity, not component because each can have associations to other classes not illustrated here.

The problem starts when the same class class-c illustrated above has associations with other classes. Suppose class-c has an association one-to-many with class-x.

class-c 1<---->*class-x

Now a composite id of two long integer has to be carried over as a foreign key into class-x. But this is manageable and often done in Hibernate. I could live with that. But there is an even worse case than that, where carrying over big composite ids becomes problematic.

I will describe this problematic situation here. In my application (which is a social network application), I have two classes like class-c and they are associated with each other by yet again a join table with attributes. This new join table class now has a composite id made of 4 long integers. That does not make sense for me. That's a bit much in my opinion. I am looking for another solution. Here is an illustration of what I just explained.

class-a 1<---->*class-c*<---->1 class-b

class-d 1<---->*class-f*<---->1 class-e

Where class-c and class-f have yet again another association with join table attributes encapsulated by a new class-g (see below).

class-c 1<---->*class-g*<---->1 class-f

The problem is that now class-g has a composite id made up of 4 long ids. This accumulation of ids into composite ids is problematic for me. I think it opens the door for all sorts of problems. I want to avoid this.

My possible solution is to use the idbag for all my many-to-many join table associations. This way, I am hoping that I can use the new id introduced by idbag in all new associations with the join table attribute class.

My questions to you is:

1 - Can I do this with Hibernate? In short, can I use idbag with join table with attributes? The centre of the question is: Can I use idbag's new surrogate id in new associations involving the association class?

2 - If yes, I would beg you to give a complete example of the xml file mapping. I prefer by far using xml file mapping.

============================
Book References (none of these excellent two books talk about his issue)
1 - Java Persistence with Hibernate by Christian Baver and Gavin King
2 - Hibernate Recipes by Srinivas Guruzu and Gary Mak

I experimented to use <idbag> with join table of many-to-many associations with attributes.

I had to use <composite-element> to map the attributes to a class. The first limitation I found is that <composite-element> does not allow the class to have any container. The only thing it allows is <many-to-one> association.

This limitation answers may question and ends my inquiry. I am disappointed.

I wish the Hibernate team would consider allowing <idbag> in many-to-many associations and using the new single key in new one-to-many associations. The benefits are important for the user.