Extensibility feature requests

[dustinywoods]

I saw this project referenced on TSS and am very interested. I was about to embark on similar functionality so I thought I'd share some of my current requirements that would be needed of this library in no particular order. I'm fully aware that these requirements may or may not fit your vision of this library but hopefully this library can be flexible enough to lay a solid foundation.

* Event listeners will be extensible enough to add 'audit' fields in addition to a timestamp (e.g. username of modifier).
* Event listeners ignored in certain cases. I'd like the option to not create the version for trivial changes like spelling corrections in text.
* If not ignored then provide a way to rank the versions to determine degree of change?
* Ability to search the versioned fields across all versions. Hotels get bought and sold often and get rebranded and I'd like the ability to search by an old name and return the current version.
* Ability to search expanded to Hibernate Search somehow to allow fulltext searching on history of names.

Thanks for taking the time to release this library, hopefully the source code is soon to follow. :)

Dustin

[adamw]

Hello!

thanks for your interest :)

I was also thinking about including some of the features you write about, and they all make good sense.

Event listeners will be extensible enough to add 'audit' fields in addition to a timestamp (e.g. username of modifier).

That's I think one of the more important features. What you could do right now, is have in your entity an additional versioned field, for example "lastModifiedUser", which would be a reference to a user who was the last to modify the given entity.

If you have several entities, that becomes a bit of a trouble; so storing this information in _revisions_info would be the best way. I haven't though yet thought of a good way for the users to plug-in information about what data they want to store and how to obtain it.

Event listeners ignored in certain cases. I'd like the option to not create the version for trivial changes like spelling corrections in text.

That's quite easy to acheive right now, just subclass org.jboss.envers.event.VersionsEventListener and override onPostUpdate(PostUpdateEvent event). The event object lets you access the entity that is being modified. Do you think there's a need to provide an additional plug-in for that?

If not ignored then provide a way to rank the versions to determine degree of change?

How could the ranking for example look like? How much text was changed? Or would it be something achievable with simple SQL?

Ability to search the versioned fields across all versions. Hotels get bought and sold often and get rebranded and I'd like the ability to search by an old name and return the current version.

That's a very important feature as well, though a bit harder to implement, as the query to retrieve the versioned entity isn't very simple. The case you write about is quite simple to achieve - it's just a matter of adding an additional clause to the "where" part of the query. So one way is to provide users the ability to specify additional conditions that should be appended to the query, for example in the "where" or "order by" parts.

Another solution, which I was thinking about, is to provide users with a restricted subset of Hibernate Criteria or provide Hibernate Criteria-like interfaces to build queries on versioned data.

I've uploaded the source code, so if you're interested just go to http://www.jboss.org/envers/downloads

Adam

[dustinywoods]

Adam,

Thank you for such a quick reply. I've been able to get this setup and do some testing and have some more thoughts on this library.

I'm already tracking lastModifiedUser through the use of an @EntityListeners annotation so making that field @Versioned is a good solution; however, it seems that this library doesn't look into super classes for fields marked as @Versioned. Is this by design?

I'll have to think about the event listener ignoring more. I was initially thinking that this would be determined through the UI as an option to the user but I'm still on the fence on whether or not this is a good idea or not since it wouldn't be strict 'versioning' but more of just 'aliasing'.

I think adding Criteria functionality is a great idea.

In addition to my problem of @Versioned fields in super classes not getting picked up I also have a problem with getting the session to flush after the versioning information is saved. I uses Spring's OpenEntityManagerInViewFilter and assume that it's changing the FlushMode to NEVER or MANUAL. The session is getting flushed at transaction commit time but before the version synchronization is done. I've solved it temporarily with an explicit session.flush() call in each of the VersionWorkUnit implementations but am not sure that's a viable solution.

Thanks,
Dustin

[adamw]

Hello,

regarding fields from superclasses not being mapped - that's probably a bug, I'll test and correct it today or tomorrow and let you know.

About the flushing - I only tested one flush mode so far, so I must have overlooked this issue. Again, I'll have to test it, but I think that your solution to add an explicit session.flush() is correct; because if there were any operations executed on the database - and hence appropriate work units executed - the session must have been flushed anyway.

Thanks for testing and the opinions :)

Adam

[adamw]

Hello,

I have uploaded a development version:
http://www.jboss.org/envers/downloads/development/
which includes a fix for the problems with subclasses and should properly handle session flushing in various modes.

Adam