I was having the same issue. Seems that ValidityAuditStrategy tries always to update the REVEND of previous version, even if the audit table is empty. This is causing problems when you are migrating to ValidityAuditStrategy or when you start using Envers with entities which already exists (then the update for these entities will fail).

Hi,

There should always be exactly one row in the audit table where revend is null for any id referring to the auditedTable (except for the auditjoinTable where the situation is slightly more complicated: there should be one row with revend null for a joincolumn / inversejoincolumn combination).

Which implies that the exception thrown in this code should be correct. However, there's probably something else going wrong.

I have seen some situations where the o.h.e.entities.mapper.relation.AbstractCollectionMapper did not create new AuditJoinTable rows. This was caused by invalid equals() and hashCode() methods.

Maybe you're seeing something similar. I'd be very interested in any testcase you can provide for this exception.

Yes that would cause problems. External modifications to the database should create audit rows as well.

Just as Erik said, if a row is added outside of Hibernate/Envers, you have to manually initialize the audit table with an initial revision, type = 0 (ADD).

Adam

Why not letting envers working fine whitout trhowing the exception in the case the audit table for that element is not initialized?

Because it shouldn't happen in normal situations - the only exception is non-migrated data.

Adam

Tercio Ferdinando Gaudencio Filho wrote:

 

FYI, I'm working on a code that will create the records in the audit table if there is none.

 

Tercio

I need something similar to what you described: I'm enabling Envers in an existing database, so the tables are full of data but the audit tables are empty. Did you find a solution for this?

I'm using PostgreSQL, so a solution for MySQL databases wouldn't help me much. From what I've researched, it seems the best place to implement this solution would be AuditEventListener. On update or delete, check if the audit table already contains the history (ie the "ADD" record) for this entity. If if doesn't, insert the "ADD" record, and then the "MOD" record.

This way no database space would be wasted for entities that were never modified or deleted, and no manual INSERT of records would be needed.

My doubt is what do about the revision number, because they are "global" and not specific to the modified entity. What do you think?

Well, but that would require an additional query on each write, wouldn't it slow things down>

The revision number would have to be the same as for the MOD, I guess.

Adam

This specific application where I need to enable auditing receives few UPDATEs, and the database is a very powerful (and under-utilized) machine so I don't think performance would be a problem. Besides the possible performance issue, do you think this approach would work?