I have a field declared as a Map<MyEnum, String>, which is audited. When a change is made to one of the elements in the map, envers is generated two edits, an ADD and a DEL, rather that a single MOD, which in turn means a constraint violation when trying to insert into the audit table, since there are two edits for a single field in a single entity in the same revision.
I’m guessing I could probably work around the problem by making revision_type part of the table’s key (which would permit one edit of each type per field per entity), but that seems like an ugly hack, besides the fact that I lose track of which happened first, and the fact that it’s just wrong.
The field is being persisted properly, by the way… it’s just the audit records that fail.
The field’s declaration:
@ElementCollection
@CollectionTable(name = "configuration_property", joinColumns = @JoinColumn(name = "configuration_id"))
@MapKeyColumn(name = "property_name")
@Column(name = "property_value", columnDefinition = "longtext")
@MapKeyEnumerated(EnumType.STRING)
private Map<ConfigurationProperty, String> properties = new EnumMap<ConfigurationProperty, String>(ConfigurationProperty.class);
I’m using Hibernate v3.5.6.
I haven’t been able to find any bug reports regarding this, so I’m thinking I’m doing something wrong… any ideas?
If you look at AbstractCollectionMapper.mapCollectionChanges, the current implementation only does additions and removals. I think the map is viewed as a collection of tuples: (key, value), so there are never any modifications. The bug is then in the schema generation, which should generate the keys properly. Please file a JIRA bug – https://hibernate.onjira.com, Envers component.