[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2208?page=c...
]
Alex Burgel commented on HHH-2208:
----------------------------------
the fix for this bug causes a new Settings object to be built for each table mapping when
doing a schema update or validate. this is unnecessary.
in some scenarios, it might be expensive to build a new settings object because it
communicates with the database for metadata and it also creates a cache provider, which
might be expensive to create for clustered caches.
to fix, buildSettings (lines 947 and 1069) should be pulled out of the while loop.
Table schema use in DatabaseMetadata
------------------------------------
Key: HHH-2208
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2208
Project: Hibernate3
Type: Improvement
Components: core
Versions: 3.2.0.ga
Environment: Hibernate 2.1 beta 4, Oracle 8i
Reporter: Adrien
Fix For: 3.2.1
Attachments: DatabaseMetadata.java, HB-534_patch.txt, TableMetadata.java, patch.txt,
patch1.1.txt, patch1.2.txt, schemavalidation.zip
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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira