This is due to the change in HHH-10133 Closed .

In 5.0.1, we determined the table name by calling into org.hibernate.mapping.Table#getQualifiedName(Dialect,String,String). This method was supplied with both the values defined by the hibernate.default_schema and hibernate.default_catalog properties and internally it prioritized the values from the @Table annotation unless they were not supplied and then it used the default property values. This method then delegated to #qualify(String,String,String) which basically then appended the three supplied strings with catalog first if not null, schema next if not null, and finally the qualified table name.

The problem was that the use of schema and catalog were inconsistent. Had I provided a connection url that used database1 and a hibernate.default_schema that specified database2, the schema generation would create all my objects in database1 but querying entities would use database2. Had I even specified the schema as database2 in the @Table annotation, the schema generation process would have still placed that object in database1. This creates lots of failures, inconsistently behavior, and confusion on the user.

With 5.0.2, we standardized the notion of schema and catalog by aligning which attribute was applicable based on the dialect in use.

So for MySQL, that means if you are using schema, such as hibernate.default_schema property or an attribute on the @Table annotation, it would have absolutely no effect on the object's name because that dialect doesn't support the concept of a schema. Changing those references to use catalog instead would generate the right object names consistently. Respectively, if a dialect supports only catalogs and a user uses schema, they'd experience the same problem and would need to make adjustments.

I understand this change in functionality occurred in a point release of Hibernate, but the functionality as it existed in 5.0.1 was inconsistent and incorrect.