Hibernate version:
2.1.6
Mapping documents:
Well that's what I'm trying to create.

I have some legacy data which has a many-to-many table which is too complex for my understanding of hibernate.

The table is:
CREATE TABLE matrixLink (
id int(11) NOT NULL auto_increment,
sourceCode char(1) default NULL,
sourceId int(11) default NULL,
sourceField varchar(40) default NULL,
destinationCode char(1) default NULL,
destinationId int(11) default NULL,
destinationField varchar(40) default NULL,
UNIQUE KEY id (id),
KEY sourceKey (sourceCode,sourceId),
KEY destinationKey (destinationCode,destinationId)
) TYPE=MyISAM;

The idea is that People, Places, Books and Images each are separate
well behaved tables, but ALL CROSS LINK THROUGH THIS TABLE (I didn't design it, okay).

It is not really a many-to-many table since the sourceField
and destinationField are additional information. This suggests
this table really becomes its own entity. Okay, I have that so far.

The descrimination is accomplished
both with the sourceCode and destinationCode columns.
Thus the same four different tables (!) are referencable from either
side of the table. This has got me stumped.

So I think a many-to-one from
each side of the table is correct, but I'm having trouble with
how to even begin to incorporate the descriminator on
both sides of this table.

So am I on the right track with:
1. Each real entity table Person, Place, Image, Book
has a one-to-many to this Link table with an extra where clause
which descriminates the right set of sourceTypes

2. The Links collections are idbags of Link class with has
4 subtypes each with a discriminator to separate the _destination_
Types.

Is that on the right track?
Are subtyped components somehow relevant or even possible
in this mix?

Anyone have any ideas to help get me going down the right path?

-Paul

Well, you could model the table as an entity with two <any>s. Querying it is going to be difficult though. This is a pretty awful model....

Okay, thanks for that lead. Yes, I see that does look like something
interesting. Since I've got to force each link to believe a
descriminator, it seems to fit my needs. Where it says "The first column holds the type of the associated entity. The remaining columns hold the identifier. " (manual section 6.4) All I have to do is provide a mapping for the little string in the database to a .class of the right kind which would be
one of my 'real' tables of entities

So then the other end, back at the well behaved People, Places, Books and Image, becomes a .. ahhh ... one-to-any? But there isn't
one of these, so I'm thinking it's maybe an <idbag ... > again with
the appropriate "where" attribute to pick up that descriminator correctly.

Note: In each regular table I had previously operated with Links that come from and links that come to the record, so there would be an <idbag ...> or
just <bag ....> for each of those associations.

So what are the challenges of querying?
Actually, in the previous version of this application, I generally
started out at one 'real' entity and generally navigated through
this funcky table: All Locations with links to Images, or All People with links to a particular Location. That kind of thing, but a future requested
feature is queries which narrow the lists across combinations of
People, Places, Books etc. e.g. Books from Places which have People who contain the text 'foo'. Note that this would pass right through this link
table twice in the same query which would be People to Links to Places to
Books.

Thanks again for the quick feedback!

-Paul