Hibernate 5.0.6 Ignores schema in MySQL

But see you just highlighted the problem I just described how SQL and JDBC are defined. Clearly MySQL is defined differently. You can argue all you want, that is the simple fact.

Really supporting MySQL needs some concept of "well MySQL uses these terms backwards, so we will need to invert the handling of them". You can "argue" all you want that @Table(name = "types", catalog = "config") is wrong for your setup (and you'd be absolutely correct based on SQL/JDBC!) but clearly that is the way MySQL is implemented.

I 100% agree with what you're saying. And that's why I'm arguing about this issue so much, don't take it personal.

In this case, "config" is one of the schemas in this catalog. I don't have a catalog named "config." My catalogs generally refer to individual database instances - e.g. my "dev" db, my "qa" db, my "uat" db. Each of those catalogs has their own unique "config" schema (the structures generally the same within the same release line, contents likely vary between dbs).

MySQL just makes the terms confusing. The term schema specifically means the collection of tables, views, sequences, etc. The catalog/database (database is the term ANSI SQL prefers, catalog is the term JDBC prefers) is the collection of schemas. MySQL supports no notion of a "collection of schemas"; there is never a time you can open a MySQL connection and refer to objects in other catalogs/databases. Compare that to, say, Oracle or SQL Server where you can refer to both "levels".

I agree that it's an opt-in behavior. My personal opinion is that having no way of restoring the old behavior is the biggest pain point in this upgrade more than anything. I think you need to include some information about migrating this situation for users here: https://github.com/hibernate/hibernate-orm/blob/5.0/migration-guide.adoc, including hopefully a list of databases and their old/new behavior for catalog/schema. I'm probably going to end up working around this by implementing a custom dialect that overrides the catalog/schema setting.

FWIW, when I read through the formal definition of catalog/schema, I would consider the mysql implementation to be catalog == server you connect to, schema == database that contains your tables/procedures, etc. I can't find catalog anywhere in their docs so it really puzzles me why their DatabaseMetaData object returns attributes indicating it has catalog support.

I few points...

I disagree. This worked fine in earlier hibernate versions.

The fact that something used to (happen to) work in a previous version does not make something a regression (as in a bug). It has to be documented in some fashion to work that way. That's not my "rule"; that's just software development. This behavior you say "work fine in earlier hibernate versions" may have in fact worked for you in your specific case. However, as I mentioned in the referenced HHH-9714, support for that was (a) very inconsistent across databases and (b) not documented to work with schema tooling. In fact prior to 5.0 schema tooling was completely unsupported, provided as a "best effort" for use by the community. 5.0 changed that to make it supported, but part of that is refining behavior and expectations.

In addition, their documentation clearly mentions create database/create schema.

That is partially true. That linked documentation does in fact show that MySQL does support creating a database (catalog) via CREATE SCHEMA as a synonym for CREATE DATABASE (catalog). What it misses, however, is the querying of database metadata that is needed for schema validation/migration. Again, as mentioned in HHH-9714, if "MySQL supports database (catalog) and schema then why does querying database metadata based on schema not work? The issue here is reflexivity. They support SCHEMA in terms of creating a DATABASE (catalog), but not in terms of querying that metadata back.

When I initially developed this supported version of schema tooling, I had hoped to allow a level of application portability here in terms of porting the use of schema/catalog in mappings to the supported construct for the underlying database. But that ran into some problems. The idea was, in your case for example, that we'd see @Table(name = "types", schema = "config") and based on our knowledge that MySQL does not support schema, but instead supports catalog we'd simply interpret that as @Table(name = "types", catalog = "config") for you. This sort of implicit "intention interpretation" always has dangers though.

In principle I am not against adding such an interpretation feature here. IMO it ought to be an opt-in behavior. If that is something someone here is interested in starting development of such a feature, let's start a discussion about it on the hibernate-dev mailing list.