Thanks for the update @Chris Cranford. An interesting direction!

Hi this is very likely outside the scope of the initial 6.0 release. The biggest issue here is the fact that these bulk operations do not load state into ORM and therefore its listeners aren’t fired on a per entity change; therefore Envers is unable to resolve state changes and write any type of audit records.

That said, I have actually given some thought to see if there is the possibility to bridge this limitation with Debezium. Essentially right now, Envers relies on Hibernate to raise events that we react to. With Debezium, we would actually no longer do this but instead, we’d rely on reading the database transaction logs for the changes and reacting to changes from that source instead.

The benefits of such a solution would be that we’d be able to react to CriteriaUpdate and CriteriaDelete operations. Additionally, we’d be able to react to changes performed outside of the entity model, i.e. changes made via some SQL client tool.

But while those benefits look really good, there are many details that would have to be worked out. We’d be moving from reacting to events based on an entity model to events based on row-level changes. That’s an entirely different model and whether we’d be able to turn those into object-model events is really where the rubber hits the road in terms of whether it's even doable.

There are also other things to consider with such a design, including setting up replication slots on PG, executing LogMiner queries on Oracle, reading the binlogs on MySQL, etc. Furthermore, Debezium doesn’t cover all dialects that Hibernate supports so the solution wouldn’t be something that’s portable across all dialect domains either.

Steve and I haven’t touched base on this recently as we’ve both been busy with our own development duties, but perhaps there are some paths like he described below that we can collaborate on and see if it would work however that’s unlikely to be anytime in the near future.

We have hit this issue too, are there any plans to try to address it?

I just do not see pre-selecting the matching ids and then inserting records into the audit tables as a viable solution. Performance does matter, and even in ORM itself there are well understood limitations to these bulk operations.

I can see a number of options though:

1. Use triggers as the basis for auditing - I've always thought this would be a great avenue to investigate anyway.

2. Extend the MultiTableBulkIdStrategy processing to also consider whether the entity is audited and let it use the populated id table. Deletes are easy(ish) here, but updates would be difficult

3. This would strictly be for 6.0, but if we do end up leveraging anon procedure blocks, we could have envers insert its statements into the block we send for the bulk update/delete.

It would be great to have support for this in 6.0! I'll keep the thread subscribed to be notified of updates, if you guys come up with something.