Generating Hibernate composite key object from hbm file

Question

(Parenthetical rant:) I'm a Hibernate beginner getting slightly frustrated by the overhead of a simple join that I could write in 15 seconds in SQL. (End rant)

The situation is thus: I have 2 tables that both contain the same composite primary key - let's call the columns in both tables 'ID' and 'Version'. I need data about a particular ID/Version from both tables, so

select a.xxx, b.yyy 
from tableA a, tableB b
where a.ID = b.ID
    and a.Version = b.Version
    and .....

Bad table design, but not in my hands.

In Hibernate, my online research suggests creating a separate composite key class to be shared by the tables, with an A object containing a B object, and a one-to-one mapping between them in A's hbm file.

In my project, all my Hibernate data objects are generated with hbm files and located in the same place. So I'd like to know if I can create this composite key object also using an hbm file and store it with its brethren. The issue is, it doesn't map to any table in particular (or, you could say it maps to 2 tables). I'm trying to determine if it's possible to create this composite key class with an hbm file, and also if it's advisable or not to do so. Am I going about this the wrong way?

Thanks in advance.

Answer 1

I think you misunderstood this key object. You should write a java class, which represents this key, consisting of a id and a version in this case. Then you use this class as composite primary key type. You can't seen anything about this class in the database. It is just used by you and by hibernate, to identify an instance.

The one-to-one relation is used to synchronize primary keys. One object should reference the other, and will get its own primary key from that.

Documentation:

• Chapter 5. Basic O/R Mapping : Mapping declaration : composite-id
• Chapter 8. Component Mapping : Components as composite identifiers

Most people who switch from SQL to Hibernate are frustrated, because they try to work with hibernate like with SQL. Then they don't benefit from it but get the additional overhead.

So here my short advise: You should not think in tables anymore. Unless you are writing mapping files, just forget tables. Only think in classes, objects and object oriented structures. Don't perform queries for everything you want to "do in the database". In most transactions, you perform a single query at the beginning, then you navigate along properties, using lazy-loading (which your code doesn't recognize). The code which implements the actual logic does not know anything about a database anymore. Then it starts to be fun to work with hibernate.