If an audited entity contains an @ElementCollection map, where the map value needs to store a large binary or text object, Envers fails to create the corresponding audit table.

For example, this will occur if the entity contains:

@ElementCollection
@Lob
private Map<String, String> embeddedMap = new HashMap<String, String>;

The issue occurs because Envers attempts to use the map property value as part of the audit table primary key. For example, based on the above ElementCollection, Envers will attempt to create a table as follows:

create table MyEntity_embeddedMap_AUD (REV integer not null, MyEntity_id bigint not null, embeddedMap clob not null, embeddedMap_KEY varchar(255) not null, REVTYPE tinyint, primary key (REV, MyEntity_id, embeddedMap, embeddedMap_KEY))

This fails (in H2 and MySQL which I tested) because a CLOB column is not permitted as part of a primary key.

This issue can be worked around by manually creating the audit table with a modified structure, using the REVTYPE column in place of the map value in the primary key. As far as I can tell, this workaround allows correct audit records to be generated for all types of revisions. Therefore, it seems the issue could be addressed by having Envers use this alternate structure by default rather than the current key containing the map value.