{{AuditReader.getRevisionNumberForDate(LocalDateTime)}} delegates to {{RevisionTimestampValueResolver.resolveByValue(LocalDateTime)}}. When the type of the revision timestamp property in our revision entity is {{Long}}/{{long}}, the argument is converted to epoch _seconds_ [here|https://github.com/hibernate/hibernate-orm/blob/6.2.7/hibernate-envers/src/main/java/org/hibernate/envers/internal/revisioninfo/RevisionTimestampValueResolver.java#L72]:
{code:java}return localDateTime.atZone( ZoneId.systemDefault() ).toInstant().getEpochSecond(); // <-- should be toEpochMilli() {code}
The result is then used as the parameter in the revision number query:
{code:sql}select max(rev) from revision_info where revtstmp <= ?{code}
However, the {{revtstmp}} represents epoch _millis_, as can be seen [a few lines up|https://github.com/hibernate/hibernate-orm/blob/46d907deb1f15965c13ade81fba8877c04b33bea/hibernate-envers/src/main/java/org/hibernate/envers/internal/revisioninfo/RevisionTimestampValueResolver.java#L44] in {{RevisionTimestampValueResolver.resolveNow(Object)}}:
{code:java}revisionTimestampSetter.set( object, System.currentTimeMillis() );{code}
As a result, {{AuditReader.getRevisionNumberForDate(LocalDateTime)}} will basically never return anything if we have a {{@RevisionTimestamp long revtstmp}} attribute.
----
Workaround: Use {{AuditReader.getRevisionNumberForDate(Date)}}, where the {{java.util.Date}} argument is correctly converted to epoch _millis_ in {{RevisionTimestampValueResolver.resolveByValue(Date)}}. |
|
