Hy, this comment to say that the issue still affects version 5.X.

And I add an observation after reading your discussion : You're speaking about inserting, as hibernate-envers-tool propose to do, the entity when not previously in the database. I have understand reading Hibernate Envers documentation that the ValidityAuditStrategy has been done essentially for performance's reasons.

So if you're planning to add a line for each row updated that is not yet in the audit tables, this is quite contradictory !

For example I've a big legacy database with some tables containing near than 100 000 000 rows. On those tables just a few percent (less than 1%) are updated by the application. So you're forcing me to insert 100 000 000 rows in the audit tables which will have terrible consequences when I want to get the historic of modification of one of the frequently modified entities... What a pity ! In that case the DefaultStrategy stay the best one for performances and I can't have the benefit of ValidityAuditStrategy logic...

The solution which consist in implementing the ValidityAuditStrategy to modify the perform method is OK... as long as in the rest of the framework, you don't supposed that for each updated entity, there must be an inserted entity in the audit table. But I'm not sure of that while reading you're discussion and, as Piotr Findeisen says it, I'll be afraid to go this way for the next versions.

As Piotr Findeisen says, I think IMHO the best solution would be to permit to unactivate this control, and in the all framework to not assume that for each entity modified, there was an entity in the audit table. I also think that with the multiplication of links between applications today, you can't suppose that the database will always be hit by the same way, passing throught hibernate envers events.

I just want to give my humble opinion. But whatever your choice will be, you're doing great things hibernate's guy, thanks for all, and excuse my bad english