Audit records for entities that weren't actually modified

[appletree]

We've migrated our old revision history mechanism over to envers and I see now that there are tons of duplicate records in the audit tables.  For example, a top level entity in our object hierarchy is updated, but no fields have changed.  Envers not only records a record for it in its _AUD table, but also for every single one of the dependent entities as well...  it's a real duplication mess.

Is envers supposed to record audit records even when no fields have been modified on an entity?  If so, how can we prevent this behavior?  Do I really have to look up in the db every single field of every single dependent entity and compare when updating an entity?

[adamw]

This can be if you have an entity with a many-to-one or many-to-many relations. A revision is generated if an entity is added or removed from the collection. This is not reflected as a change to a DB field, but a field in the entity is somehow changed, hence the revision. You can turn this off by setting the

org.hibernate.envers.revision_on_collection_change

configuration option. See the manual for more details.

Adam

[appletree]

That setting didn't help.  We aren't modifying any relationships, nothing's being modified... well things are being hibernate updated, but there are no actual changes.  There's a bug somewhere, probably in our code.  But I would hope that envers wouldn't have allowed this to happen.  I'll report back once I've thoroughly debugged the situation.

[adamw]

Hmm that's interesting. Let me know if you find out anything, I'm curious what's happening too

Adam

[rsvato]

Hello Adam,

Event with this setting new revision is created for the object if any of its persistent collections changed. I prepared a small test case for it here: https://github.com/rsvato/audit-cascade-demo

Book has many authors. If you create author and set a book for him, no revision for book is created, but if you add new author to the authors collection, new book revision is created with new author. Is it expected behavior?

[appletree]

So yes it makes no sense that a new Book revision is created in Sviatoslav's example.  There's also a more insidious problem in our case, and I assume in the Book/Authors testcase above, in that any one-to-one or one-to-many entities in Book will also get unnecessary revisions when none of them have changed.

[florin13]

Hi guys,

I've looked in the Book/Author testcase. A bidirectional one-to-many relationship with the "one" end set as the owner is correct from the hibernate annotations point of view. This is an excerpt taken from the hibernate annotation documentation regarding this kind of relationship:

"To map a bidirectional one to many, with the one-to-many side as the owning side, you have to remove the mappedBy element and set the many to one @JoinColumn as insertable and updatable to false. This solution is not optimized and will produce some additional UPDATE statements."

Could these additional update statements be the reason envers creates the non-sensical revisions?

[rsvato]

Additional update statements occur when you use this insertable="false",updatable="false". In this case Hibernate insert record, and after it updates it. But it's not the case of example. Moreover, how I'm understanding, Envers relies on session state rather than on database updates.

[adamw]

Well with the default setting (org.hibernate.envers.revision_on_collection_change = true) I think a new Book revision should be created both when a new Author is created an when an author is changed. With org.hibernate.envers.revision_on_collection_change = false there should be no Book revisions.

Maybe you could create a JIRA for that, and convert your test to an Envers testcase?

Adam

[rsvato]

Thanks for answer.

I created a JIRA issue some time ago. It's http://opensource.atlassian.com/projects/hibernate/browse/HHH-5756. If you'd like, I'll convert test to a Envers testcase.

[adamw]

Ah great, thanks. A test case is always very helpful. If you've got the time, maybe you'd want to attempt to fix the issue - just clone the github repo and send a pull request later

Adam

[rsvato]

Fixed for branch 3.6. Could you please look at it before pull request?

This is commit link: https://github.com/rsvato/hibernate-core/commit/3091bbda15b24a0bdf330f4f48b2772616b70583

Problem is that onCollectionAction() method of AuditEventListener class completely ignores setting org.hibernate.envers.revision_on_collection_change