The use case is outlined in this thread.
Sometimes users enable Envers on an existing database without considering that they must first seed the audit schema before Envers' first use. In this case, typically users will need to update all existing audit rows by incrementing the revision number by 1 so they can then proceed to seed the audit schema with revision 1. This can be a daunting and tedious task.
The idea is to allow an opt-in configuration property that is disabled by default that relaxes the revision number restriction used by a variety of reader interfaces that permit the revision number to be >=0 rather than >=1. This way seeded rows can be added after-the-fact using revision number 0 easily without imposing the need to remap all revision numbers. Since this is an opt-in feature, it simply allows users an easier way to deal with this use case if they find they need it. Its an opt-in feature that the user code would need to manage what revision number 0 means if used.
The expected impact is to AuditReaderImpl, CrossTypeRevisionChangesReaderImpl, and AuditQueryCreator.
Perhaps a property called
The business logic for generating revisions would remain starting at 1 and increment thereafter. The property is simply mean to relax the query-side to permit 0.