We have a logical many-to-many relationship between Person and Address, with a PersonAddress association entity in between.

As recommended (and the arguments provided do make sense!) by the Hibernate information reviewed so far (ref. doc. on Hibernate.org, HIA, JPwH, this forum, etc.), we are implementing the above logical many-to-many relationship as two one-to-many ones.

And as seems a common practice (if not a recommendation --a couple of places say that this is "quite arguable", if memory serves--, and although it makes sense, at least initially --e.g. until you start thinking about history--), the PersonAddress has a composite id (natural key) containing the personId and addressId.

Now, we would like to cascade inserts (in fact, all CRUDs) in the database from Person to PersonAddress, but:
* since Person.personId is generated it is not available before flushing;
* since PersonAddress.personId is however assigned it must be available before flushing...

This contradiction seems impossible to reconcile? Reason for which I've been recommending to use a surrogate key on PersonAddress as well. This is also consistent with the common realization that association tables typically end up with data of themselves, i.e. that a table is a table and flagging some as "association" tables is an artificial and problematic inconsistency.

In other terms (and DBAs allowing...), ALL tables should have surrogate keys to follow the many-to-many (and other) recommendation(s) all the way through and try to keep things consistent, simple, flexible, etc.

But I am interested in any thoughts on the above!

Hello all,

I am still interested in any ideas or pointers confirming or challenging the thoughts below.