The title of this post might sound a bit strange. Let me explain:

I have two classes A and B, mapped to two tables, A and B.
There is a many-to-one relation between the two (let's say that A owns the foreign key)
Both entities have a surrogate primary key (say, a native generated key).
Ok.

Now, B has a column, code, which is unique, and so which might be the primary key as well, but, for various reasons, we don't want it to be the primary key, and so we stick to our surrogate numeric keys instead.
The problem is...
Suppose I have to persist a detached instance of A, and A owns a detached instance of B.
Suppose that B.code=Richard, and I don't know the value of B.id (not yet), so B.id=null
Suppose that there is a record, in the table B, whose column code contains Richard too.
I cannot persist A and B in a single operation, otherwise a violation of unicity constraint will be raised (since Hibernate will try to make an INSERT into B).
So I have first to retrieve the persistent instance of B corresponding to "code=Richard", set it to A, and persist the whole.
But this is long, and I would like to run a single cascading saveOrUpdate on A.
Actually, I would like Hibernate to do the SELECT for me, and let it decide if it should execute an UPDATE or an INSERT for B.

You might reply: use code as the primary key then. Yes, it works, but I want to use a surrogate key, like it is generally advised.
Any idea to do this in Hibernate ?

Thanks a lot for your answer.

As far as I know Hibernate is only able to take action on the primary key/id property of an entity. It seems like they are planning something at least with loading an item by natural key for Hibernate 3.6 (see http://opensource.atlassian.com/project ... e/HHH-2879).

So for now, I think you need to do the lookup yourself. You may have to do that in the future as well, but the new api should probably be a bit easier to use and may also be support caching. If you have a DAO you could for example have a method getBByCode(String code) that takes care of everything. Eg. check if a B with the given code already exists. If so, use that, otherwise create a new one. You could even have your own cache implementation if needed. Then, when Hibernate has implemented a new API, you only need to change the implementation in the DAO.

That's interesting.
Yet, it seems that this would just give <natural-id...> more or less the same functionnalities of <id...>. I am not sure this would allow for the use of the two at the same time!

Actually, I'd like to keep my good old surrogate <id...>, while having a better control on how the save-update process works. I'd like to say to Hibernate: your decision to insert or update a record not only depends on the value of the <id> key, but also on the value of another property (which could be a natural-id key, or just a "unique" property).


Yes, that's what I ended up doing! :-)

I'm going to have a look at the current JIRA issues, and see if it's worth posting a new improvement request for that.
Thanks for your answer anyway.