Hi

I'm facing another issue after upgrading to Hibernate 5.2.8

When running my app I find that auto ddl is creating new audit tables with suffix _aud. This happens because it doesn't recognise the already there

So I set property and it continues to fail. I then try to set it to any other name with UpperCase, and it just translates them to lowercase

At a last attempt to solve this I change naming strategy to: , with no results

Is there a lower-uppercase setting in hibernate that I've failed to find in jboss docs?

Also it doesn't seem to make much sense, provided that in https://docs.jboss.org/hibernate/orm/5.2/javadocs/ it says that suffix defaults to _AUD with uppercase

EDIT to include latest test:

I also tried to annotate an entity with Once again, the table was named all in lowercase

The suffix is _AUD, as you can see in the Envers chapter in our User Guide.

If you log the JDBC statements, you will see that they are in uppercase.

I suspect that either the underlying file system or the database case sensitivity is the problem here.

Hi Vlad, thank you for your reply



It may well be the case that my system has something that the newer version of Hibernate doesn't like, but when I put the version back to 4.3.6 in pom file it builds new Audit tables in DB with capitals on the suffix, if I switch to 5.2.8 it does it with lowercase only. I've trialled with clean local databases to rule he database case sensitivity out

EDIT to add latest tests

As a matter of fact and mainly out of curiosity, the uppercase works fine all the way up to v4.3.11 and begins to be inconsistent with v5.0.0, I'd be really hesitant to calling this an issue on my end, I've thoroughly trialled this with clean databases and more than 10 different versions and it will only happen from v5 upwards

If you get the Hibernate ORM code from GitHub and run this DefaultAuditTest, these are the tables that get created:



So, it works as expected. Try it yourself and check the SQL logs.

I wouldn't expect ImprovedNamingStrategy to solve your issue because that strategy inherently will return a lower-case table name. Furthermore, the NamingStrategy contract has been deprecated particularly because of its lack of flexibility.

Are you specifying a custom ImplicitNamingStrategy or PhysicalNamingStrategy by any chance?

Hi Vlad, this is what I was trying to say from the beginning, hibernate has an embedded "toLowerCase" somewhere, and this happens only on the latest versions, there is no documentation for it and makes implementations a headache, after two days with this and with the help of my senior developer we figured that if we set property in .yml file to:

naming:
physical-strategy: org.wwarn.drugquality.config.HibernateAuditTablesNamingStrategy

Where HibernateAuditTablesNamingStrategy is a customised class that implements PhysicalNamingStrategy and Overrides all its methods returning the identifier, it's the only way Hibernate will be case sensitive when creating ddl from @Table annotated classes

Still, we cannot replicate it. Just fork Hibernate ORM from GitHub and run the tests I mentioned. The tables are generates properly whenever I build the project.

This likely explains why you're observing that behavior and we are not.

The spring-boot project automatically injects two strategies of their own when configuring Hibernate (IIRC):

1. org.springframework.boot.orm.jpa.hibernate.SpringPhysicalNamingStrategy
2. org.springframework.boot.orm.jpa.hibernate.SpringImplicitNamingStrategy

If you look at the source of their naming strategies (particularly physical), you'll notice that if the JdbcEnvironment is configured to be case-insensitive then Spring's implementation will automatically enforce lowercase. As Vlad mentioned, Hibernate by itself will create database objects without adjusting case unless otherwise told via specific strategies. So this isn't a bug with Hibernate but simply how Spring decided to integrate their version. Obviously you specifying a custom strategy of your own overrides the Spring equivalent allowing you to achieve the desired behavior. I'd also think that by telling Spring to not use a strategy would accomplish the same behavior.