I have a fully working many-to-many mapping using a bag, and have been using this mapping for quite some time. I tried switching the bag to a set, both in code and the mapping file, and all of a sudden I receive this mapping error:



Only the BuildOrder takes part in the many-to-many relationship between FreightOrder and Project:


The 1,n,m indicate the arity of the relationship, so Project:FreightOrder is n:m (the many-to-many I'm trying to map), Project:BuildOrder is 1:n (one-to-many), etc.

I'm not sure how the DocumentMap object is getting involved; BuildOrder has a one-to-many relationship via a dictionary with DocumentMap, but it has nothing to do with the above that I can see.

Hibernate version: 1.0.4

Mapping documents:

Change "bag" to "set" above, and it triggers the error. Any ideas what this might mean?

I've now tried changing it to a map instead of a set, and I receive the same non-sensical error: "Foreign key in table DocumentMap must have same number of columns as referenced primary key in table BuildOrders"


Can anyone give me a hint here? I have working sets, maps and bags all over my project, so it's not a simple mapping mistake. This error doesn't make any sense to me.

The only thing I can think of is that for some reason the more stringent <set> and <map> semantics are getting confused because your table BuildOrders is not a mere linking table, but is also mapped to an object that carries at least a collection.

In this case it would seem to make more sense to map this relationship via BuildOrder as an association class. That is, instead of a *-* from Project to FreightOrder, you would have a *-1 relationship from BuildOrder to FreightOrder in your collection, so the FreightOrders for a Project would be available by iterating over you BuildOrders.

However, in that case it would be more difficult to ensure that a given FreightOrder appeared only once per Project (which is what the <set> mapping would achieve). Using a table in two different places like that seems like it would get you in trouble in general, though. To me, the question isn't "why doesn't this work with a <set>" as "why did it work as a <bag>?" The potentially deleterious side-effects of modifying underlying data from two separate places (that are unaware of each other!) would seem to outweigh any benefit.

I suspected something like this might be the case, but I was hoping for some definitive confirmation that I couldn't do this.



Indeed, but I took protective measures against such duplicate modification. The Project.FreightOrders collection is read-only and no changes are ever written back to the database via this association.

The advantage is that I can load and display the list of freight orders without having to load all the build orders, and it would save me time and effort, and reduce code that I then have to maintain.

Okay, so you apparently thought that out well ahead of me!

Out of curiosity, though, what is the need for a <set> or <map> when the <bag> should do everything you need it to?

Set and map eliminate duplicates. I can eliminate them manually of course, but it's superfluous code really.