I came across a problem today when trying to backport this into 5.4.

In the example provided in the issue description, the idea was there was a

@ManyToOne
@JoinColumn(name = "some_other_id")
private SomeObject object;

When the association’s foreign-key is a single column, there really isn’t much problem by implementing behavior to set the modified column name to be some_other_id_MOD, however when the foreign-key consists of multiple columns, then this raises the question of should that modified flag column be represented.

Lets assume we have this mapping:

@ManyToOne
@JoinColumns{
  @JoinColumn(name = "column_id1"),
  @JoinColumn(name = "column_id2")
})
private SomeObject object;

It makes no sense to me to add both a {{column_id1_MOD}}and {{column_id2_MOD}}column to the audit table mapping, because we aren’t concerned with whether part of the foreign-key changed but rather whether or not the associated entity as a whole changed.

Therefore I’m inclined to follow these rules for the improved strategy:

• If property is a basic-type (single column valued attribute), use the modifiedColumnName attribute if supplied, otherwise use the resolved column name with the suffix appended.
• If property is an association and the foreign-key association consists of a single-column, treat the resolution of the modified column as if its a basic-type (single column valued attribute); see above.
• If property is an association and the foreign-key association consists of multiple columns, use the modifiedColumnName attribute if supplied, otherwise use the property name with the suffix appended.
• If property is an embeddable, retain legacy behavior. In this case, use the modifiedColumnName attribute if supplied, otherwise use the embeddable property name with the suffix appended.

The latest two are obviously less than ideal; however I believe that gives the most possible flexibility while not really changing the behavior all too drastically.

Tuomas Kiviaho, I’ll open a separate issue on this as a follow-up as I don’t want to mix too many concerns.