During the application startup, I've got this error (Liquibase have created AUD tables yet):
As I see, the root cause is the Liquibase part. I've created the foreign key yet, but Envers doesn't check that.
Spring Boot 2.1.3.RELEASE
Can you give me the name of both constraints? The workaround for you would be to drop the constraint that is not called FKcc7vlgg86eqe1dmvivbkv046v and let Hibernate build this for you.
Can you find reference in your LiquiBase scripts or otherwise that explain where the other constraint not named FKcc7vlgg86eqe1dmvivbkv046v came from or how it arrived in your database?
Thank you for your help. Today, I’ve figured out an another workaround, I switched ddl-auto: updateback to ddl-auto: validate
In this case, Híbernate Envers does not hang up during application’s startup.
Actually, this is a good solution, because all of DDLs are run by Liquibase.
I’m using @ForeignKey, @Index’s name element and Liquibase constraintName/indexName to ensure that both are the same but (as I see) there is no way to configure the name of auto generated constraints in Envers unlike ORM.
Could you add your entity mappings to the jira? While you've worked around the issue at hand, it would seem for Envers to better integrate with tools such as LiquiBase, perhaps there is an enhancement to be made out of this.
There is no way to customize that foreign-key name currently and that is somewhat intentional.
The FK relationship you shown is just one of many different relationships that get built automatically as a part of the Envers metadata model. In order to do this properly, we need to consider all avenues.
1. DefaultAuditStrategy: REV column -> REVINFO.
2. ValidityAuditStrategy: REV column -> REVINFO and REVEND column -> REVINFO.
3. Potentially others between audit tables
4. What about those added by custom AuditStrategy implementations?
In general the accepted practice has traditionally been to let Envers build its schema. From there export the schema to a script and supply that as a part of your Flyway/LiquidBase/etc migration strategy.
Hopefully going into 6.0, there will be some new Schema Migration tooling improvements that will allow you to be able to specify how schema migration happens per component level. For example, you could have ORM tables set to validate while you would allow the Envers tables to be set to update, therefore allowing Envers to morph as it deems necessary if you wanted.
I could see an annotation that perhaps would work solely for (1) and (2). Another annotation could be introduced to handle the potential use case of (3) if such a case exists. As for (4), that's what I am unclear on.
I think for now, its probably best to consider classifying this as an improvement/enhancement as this isn't a bug.
Thank you for the clarifying, I totally understand your position and it’s acceptable for me.