[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3365?page=c...
]
Eric Sirianni commented on HHH-3365:
------------------------------------
I'm not on the hibernate team, but I don't think this is a bug. If you look at
the javadoc for java.sql.DatabseMetaData.getTables(), if the schemaPattern is not input
then all tables maching the tableNamePattern are returned:
"schemaPattern - a schema name pattern; must match the schema name as it is stored in
the database; "" retrieves those without a schema; null means that the schema
name should not be used to narrow the search"
If multiple tables match the tableNamePattern, hibernate just picks the first one. I
guess you could argue that hibernate should error in this case.
If you want hibernate to properly filter based upon the schema, then set the defaultSchema
in the hibernate configuration:
cfg.setProperty(Environment.DEFAULT_SCHEMA, "your-schema");
SchemaUpdate still fails if conflicting table is visible in another
user's tablespace
-------------------------------------------------------------------------------------
Key: HHH-3365
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3365
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.1, 3.2.6, 3.3.0.CR1
Reporter: John Wood
Priority: Minor
This issue is a duplicate of HHH-2208. Despite what that other issue states, this
doesn't seem to be fixed.
This issue still seems to a problem for us when using the SchemaUpdate tool to
auto-update our tables (in Oracle).
We've tried this using the following hibernate versions: 3.1, 3.2.6ga, 3.3.0.CR1
In every case the bug still happens: the schema update tool tries to update a table
called "JOB", finds a table in someone else's schema (which happens to have
been made public), and then gets confused. It will either try to update the other
user's JOB table, or (in our case), fails because it (quite rightly) doesn't have
permissions to change the other user's table.
Here is how to reproduce:
1) Create your main DB user as normal (user1)
2) Create another user on the Oracle same database (user2)
3) On user2 create a new table which conflicts with a table in your generated DB
("job").
4) Make this new table visible to user1. One way of doing this is to give
"insert" privildeges to "public":
grant insert on user2.job to public
5) Run the schema update tool for user1. This will fail: it tries to update the table in
user2's schema (tablespace), and doesn't have permissions.
Note that this issue only occurs when the conflicting table is visible to user1: if the
table was hidden (i.e. user1 had no visibility of the conflicting table), we would be OK.
It seems to me that either A) there is some confusion about when this issue was fixed, or
B) this is a different issue to HHH-2208
--
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