Hi,

I have 2 classes having a many-to-many relationship between them.
In the database, I have 1 table per class + a join table.

This join table has the form:

Relation_ID (PK)
Table1_ID (FK)
Table2_ID (FK)
Additional_Field

There is a unique index on Table1_ID and Table2_ID.

To map that relationship, I use the idbag collection type.
I think this is the only collection type that can handle this case; when a surrogate key is used for the join table.
The idbag mapping element has an additional sub-element <collection-id>, with a generator that set the primary key of the join table (RELATION_ID).

Correct?

Does this mean I can't use a Set (unique elements) or a Map (unique and useful) when the join table has a surrogate key?

In our current and well established schema, every many-to-many join tables and one-to-many "many" table use surrogate keys.
Does this mean I have to use the idbag collection type only in all my mappings?

If that's true, I'm thinking of removing all those surrogate keys in the schema.

Thanks in advance,

Humm....

Suppose I have Version, Language and VersionLanguage.

VersionLanguage is a class used to store the extra information about the many-to-many relationship between Version and Language. In this case, the field Default.

The Version_Language table has a surrogate key.
A version can't have the same language twice. So we want to use a Set.

I think I could do the following:

Map the class Version
Map the class Language
-> Map the class VersionLanguage, since it has a surrogate key

It didn't sound right to me to map VersionLanguage, but since it has this surrogate key, I now think it should be mapped as any other entity.

The idbag is a solution for not have to map the VersionLanguage class, but since it allows duplicate, it doesn't resolve my problem.

Should we expect idset and idmap to be added to the supported collection types?

For the moment, should I map the "relation" class as I just described?

Thanks