Fix for HHH-2208 rebuilds Settings for each table mapping
Description
When using SchemaUpdate, the DatabaseMetaData.getTableMetadata() looks for a table with the correct table name in any database schema and it take the first one it found. This behavior is uncorrect if I have a table existing in different schemas.
The correct behavior would be to first look in the schema with the login name and after in any schema.
user1.article user2.article
I connected whith user2, DatabaseMetaData should first look for user2.article, then if not found to %.article.
i used the "clone this issue" button to create this case. which is why it has the same description as HHH-2208. i didn't realize it would create the exact same issue without allowing me to edit it first.
you can ignore the description and mark this as a duplicate of
you can also use my patch for HHH-2251, its really trivial.
Max Rydahl AndersenNovember 17, 2006 at 8:40 PM
btw. the correct way of doing this is by specifying the default schema.
Max Rydahl AndersenNovember 17, 2006 at 8:32 PM
the buildSettings() bug i'm fixing in another case.
The "correct" behavior you describe above is not correct for databases where the username does not correspond to the default schema (e.g. almost anything else than oracle)
Alex BurgelNovember 17, 2006 at 8:22 PM
a patch to pull buildSettings() out of the while loop, so its only built once per schema update/validate, rather than once per table mapping.
this is based off of /tags/v321/Hibernate3
Alex BurgelNovember 17, 2006 at 8:21 PM
the fix for hhh-2208 causes a Settings object to be rebuilt for each table mapping when doing schema update or validate.
When using SchemaUpdate, the DatabaseMetaData.getTableMetadata() looks for a table with the correct table name in any database schema and it take the first one it found. This behavior is uncorrect if I have a table existing in different schemas.
The correct behavior would be to first look in the schema with the login name and after in any schema.
user1.article
user2.article
I connected whith user2, DatabaseMetaData should first look for user2.article, then if not found to %.article.
Adrien