How to retrieve the modification flags with Hibernate Envers

I am a (rather happy) user of Hibernate Envers for auditing changes in some of my apps.

I am most often using queries such as :

    AuditReader ar = AuditReaderFactory.get(em);
    List<Object[]> auditResults = ar.createQuery().forRevisionsOfEntity(MyClass.class,  false, true)
            .add(AuditEntity.id().eq(id))
            .getResultList();

to retrieve the successive versions of an entity.

However, I see no way to leverage the modification flags that I have activated with org.hibernate.envers.global_with_modified_flag.

I can, of course, do a native query on the _audit table, but, well, it seems to me to me more a hack than a real solution.
What would be great is to have an option to get an additional fourth object in the query results.
It could be a List of modified property names…

@Naros can you help @lpenet with this question about Envers? Thanks.

Hi @lpenet!

This is actually something that was requested in HHH-8058.

The simpliest idea was to do exactly what you suggested, as a part of the object array return, we would include a list of properties that were modified at that revision:

    /**
	 * Creates a query that selects the revisions at which the given entity was modified.  Unless a
	 * projection is set, the result will be a list of 4-element arrays, containing the following:
	 * <ol>
	 *     <li>The entity instance</li>
	 *     <li>Revision entity, corresponding to the revision where the entity was modified.  If no custom
	 *     revision entity is used, this will be an instance of {@link org.hibernate.envers.DefaultRevisionEntity}.</li>
	 *     <li>The revision type, an enum of class {@link org.hibernate.envers.RevisionType}.</li>
	 *     <li>The names of the properties changed in this revision</li>
	 * </ol>
	 * Additional criterion may be specified to filter the result set.
	 *
	 * @param clazz Class of the entities for which to query.
	 * @param selectDeletedEntities If true, the result set will include revisions where entities were deleted.
	 *
	 * @return the audit query
	 */
	@Incubating(since = "6.0")
	public AuditQuery forRevisionsOfEntityWithChanges(Class<?> clazz, boolean selectDeletedEntities);

As you’ll notice this was planned to be included as part of 6; however I can go ahead and move this up to be included in the upcoming 5.3 release if that would help you.

What I’d like to hear from you is whether or not this is going to be sufficient for your needs. Ideally I prefer to keep things like this as generalized as possible but also make sure it supplies ample information that it can be useful across a variety of situations.

Thoughts?

It looks great to me. What you describe is exactly what I am looking for.

I vote for it and awaiting for this change!!!