I know. I was simply doing some comments trying to explain the problem with lesser words. Thank you so much for the fix

,

I am simply pointing out that using this type of mapping with Envers introduces 2 failure concerns, depending on whether B is null or whether B is not null. When B is null, this introduces the NULL not allowed for column 'B_ID' error which comes from the fact that Envers doesn't recognize that you have mapped the relation as optional. When B is not null, this introduces the referential integrity error which comes from the fact that Envers didn't map the relation for entity B as being the inverse.

@Chris Cranford you're wellcome. In response to your comments:

1. B relation is null initialized in class A definition as best practice and the DDL is auto generated by Hibernate
2. As you can see in the debug log Envers populates first A_AUD and then A_B_AUD. The problem is that a.getB() may be null and A_B_AUD doesn't allow null relation by autogenerated constraint in field B

I hope this helps

I am actually seeing two problems with this test case, depending on how the user initializes this relationship.

1. NULL not allowed for column "B_ID"
   This happens when following the specified test case, A is persisted with an explicit value of null for B.

2. Referential integrity constraint violation: "PUBLIC.A_B_AUD FOREIGN KEY(A_ID, REV) REFERENCES PUBLIC.A_AUD(ID, REV) (1, 1)
   This happens when the relationship is set between A and B. It appears that Envers attempts to populate the A_B_AUD table before having populated the A_AUD table; thus creating this constraint violation with the join table.

thanks for the test case.