Table schema use in DatabaseMetadata
Description
Attachments
7
is duplicated by
Activity
Show:
Max Rydahl Andersen November 17, 2006 at 8:18 PM
arh crap!
Alex Burgel November 17, 2006 at 8:07 PM
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.
Max Rydahl Andersen November 3, 2006 at 3:20 PM
fixed - schemaupdate/validate should now be better at handling multiple schemas
Anthony Patricio October 9, 2006 at 5:12 PM
here is a new patch
Jens Schumacher August 7, 2006 at 6:27 PM
Thanks for the update.
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