I'd like to configure some (not all) tables so that reverse engineering generates this:



I.e. the header of the class would then look like this:



Background:
People keep updating tables via SQL or Access but forget to update the VERSION field as well. They are willing to do it, but it's simply too easy to forget, and I'd like to plug this source of inconsistencies once and for all.

I have been considering using a trigger to update the VERSION field. The main points against this would be that our users are not used to tables that change their contents "on their own" when they access it though Access or SQL, and that it's another thing on an already-too-long list of things that need to be done right when creating a new table.
Also, triggers are not portable across RDBMSes. It would be nice to avoid the additional work for recreating the triggers in a new database dialect.

The caveats against optimistic locking without using a VERSION field do not apply: The applications accessing the database does not use detached objects.

The above example code uses OptimisticLockType.ALL.
I foresee that I'll be wanting to use OptimisticLockType.DIRTY to avoid too much contention. In that case, I'll want Hibernate Tools to generate


On another tangent:

I believe Reveng is missing one important feature: it should have a way to manually specify annotations/xml for tables and properties (and maybe other things).
That way, people would have a fallback for those situations where Reveng Is Not There Yet.
Writing strategy classes and templates would be an alternative, but that's simply much more work on the points of finding out what to do, code to write, and time to debug. It's also much more indirect: I found myself wanting to have THIS annotation THERE, as in the above case. Writing a template or strategy begins to make sense once repeated patterns emerge in the manually added annotations.
Just my 2c on that one.