im having troubles, to work with a table, that doesnt have a key.
i have a table, that is a menu-item and a table, that maps userIDs to menuitem IDs. the second table knows which user sees which menu items.
since hibernate needs for everything a key. im wondering, how to get for an user his menu items.

menuitem table:
KEY miid int(11)
name var-char(22)
image var-char(22)


menuitem_for_user:
miid int(11)
uid int(11)


Hibernate version:
3.0

Mapping documents:
<hibernate-mapping>

<class name="internal.MenuItem" table="admin_menuitems">
<id name="miid" type="int">
<column name="miid" sql-type="int(10)" />
<generator class="identity" />
</id>
<property ... />
<join table="menuitem_for_user" >
<key column="miid" />
<property name="uid" >
<column name="uid" sql-type="int(11)" />
</property>
</join>
</class>

</hibernate-mapping>

How do you select a row from a table which has no key? By filtering through all columns, I suppose... right?
So, if that's the way... the key of your class must be all properties. Everything composes the key.

Just my 2 cents, though.

Not really. If you have a User Table thats mapped to a user object and a menuitem table thats mapped to the menuitem object, you can traverse the menuitem-users table using either the user object or the menuitem object. Why would you need to explicitly create a class for the join table?

Where is the trouble?

The menuitem_for_user table has a key candidate, and it's (miid, uid). It wouldn't make sense to have duplicate records with the same (miid, uid), would it? (In that case, this table wouldn't even be a proper relation.)

So you can decide to make this the key, as moonlight suggested. If you are uncomfortable with that, and if you may influence the table design, you can also introduce an id of its own in menuitem_for_user, as recommended in the Hibernate literature.

While it would be possible to implement the whole thing as a many-to-many (which is what I take from rajasaur's posting), the Hibernate authors and most data modelers recommend to resolve many-to-many to 2 one-to-many. This concurs with my experience: You will need additional properties on the intermediate class eventually, so why not introduce it from the beginning.