I have not solved this yet, but I have a new theory, and it may leave me stuck. First, the revisionNumberPath property appears to be used only to build various read queries. Second, Envers appears to delegate to Hibernate to create the association between the REVISION table and the MYENTITY_AUDIT table. Hibernate consults the MYENTITY_AUDIT table meta-data and discovers that ID is the primary key and uses that. (Envers names the target field on MYENTITY_AUDIT as whatever I have configured as RevisionNumber field [REV_ID in my case], but nonetheless hands it off to Hibernate as a relationship via that field. Note, I have not defined a FK relationship in my DDL.)
That's my working theory right now, and if correct, I may be stuck. (I am willing to change some Envers code, but not a lot of it.)
Perhaps Hibernate would interpret the meta-data differently if I modeled the FK relationship (if my theory is even on the right path).
yes, that's true, all of the audit entities have a relation to the RevisionEntity entity, plus it's used in read queries.
But in fact, to implement your use-case correctly, don't you think that the audit entities should still have a relation to the RevisionEntity based on the PK (so in the audit tables, you would have the UUIDs)? And the revision number would be used only for reading?
Unless I'm missing some vital point I think it should work