When generating the database schema using the Hibernate property
The column name of the entitiy tables is correctly changed into the value provided via the Hibernate property
but the name of the column of the Envers table revinfo is still REV which can lead to confusion when e.g. storing the DDL scripts externally.
One interim solution would be to provide your own custom revision entity implementation so that you can specifically assign the column names to the various REVINFO attributes that you'd like to use for consistency in your database schema. The behavior you experience only occurs when using the default revision entity implementations as the column names are static and don't change based on user customizations.
, I'm actually considering a slightly different approach and would like your input.
If we change what org.hibernate.envers.revision_field_name influences, this introduces a backward compatibility issue. We either have to allow a secondary configuration property that allows the behavior you are asking for (disabled by default) or allows legacy implementations to disable the behavior to remain consistent with their current schema (enabled by default).
One option is we introduce a new configuration property to allow you to also influence the naming in the REVINFO table so that you can have column name consistency. But I feel doing that will only lead to situations where users will want additional properties to customize the other attributes of the revision entity such as the timestamp column name, the name of the table, plus the modified entity names feature if they're using that. It's at this point I take a step back and question why introduce all these configuration properties when users can already customize all those features to their liking by merely introducing their own revision entity implementation to the mix as I suggested previously.
I feel the the documentation is already fairly clear that the org.hibernate.envers.revision_field_name targets the audit entity and not the revision entity. But what we could do for clarity sake then is to add a note so that if users wish for consistency between the revision entity and their audit entity tables, they should consider a custom revision entity implementation and override the column names as desired.