|
|
|
There are times when we need to understand whether a dialect/database supports the use of catalogs and/or schemas. Generally speaking these boil down to: # Rendering a qualified name # Querying DatabaseMetaData # Extracting names (e.g., from DatabaseMetaData results).
The first and the third are actually pretty simple, and 5.0 has great isolated hook point for these already ({{org.hibernate.engine.jdbc.env.spi.QualifiedObjectNameFormatter}} and {{org.hibernate.engine.jdbc.env.spi.IdentifierHelper}}, respectively). And actually I think the second can be handled from {{org.hibernate.engine.jdbc.env.spi.IdentifierHelper}} as well.
As for porting to 4.x, that would require finding corresponding hook points since the above mentioned contracts do not exist there.
The impact of these shortcomings is evident in SchemaUpdate and SchemaValidator.
----
Currently, when a @Table does not have the catalog or schema defined, Validator will look for that table in all visible catalogs/schemas. If it is found, then Validator does not throw an exception.
Instead, Validator should only look in the default schema and/or catalog and throw an exception if it is not found.
The difficulty is that Hibernate does not understand which databases use catalog, which use schema and which use both. It needs to know this information in order for Validator to look in the right place when a @Table has a default schema or catalog.
A new API, SchemaSupport, is intended to resolve this complication.
|
|
|
|