net.sf.hibernate.tool.hbm2ddl.DatabaseMetadata:

public TableMetadata getTableMetadata(String name) throws HibernateException {
TableMetadata table = null;

if (name!=null) {

table = (TableMetadata) tables.get( name.toUpperCase() );
if (table==null) {
String[] types = {"TABLE"};
ResultSet rs = null;

try {
try {
//modified by gxh 2004.9.15 from "%" to meta.getUserName()
//rs = meta.getTables(null, "%", name.toUpperCase(), types);
//why search in all schema??
rs = meta.getTables(null, meta.getUserName(),
name.toUpperCase(), types);
while (rs.next()) {
if (name.equalsIgnoreCase(rs.getString(
"TABLE_NAME"))) {
table = new TableMetadata(rs, meta);
tables.put(name.toUpperCase(), table);
break;
}
}
}
finally {
if (rs!=null) rs.close();
}
}
catch(SQLException e) {
throw new HibernateException(e);
}
}
}

return table;
}

eh? we search all schemas since the tables can be in multiple schemas.

that is not a bug, but a good way to make the system run a tad slow ;)

But if user create a DB connection and write SQL like "insert ....into tablename" without point the schema name, he may get the unexpectable result, especially when more than one schema has the same tablename.
I ever encountered the problem and I have to revise the source code to resovle the problem.

eh no, since all the dbs i know will have a default schema selected (e.g. on oracle its normally aligned with your username)

But if the user has a DBA privilege which can access multiple schema, how can he know which table to insert into?

that does not matter since there is a *DEFAULT* schema selected. doh.

There is a problem though if the table does not exist in the default schema. I"m not sure if it's related to this, but it's an issue I'm currently having with the SchemaUpdate. It checks if the table exists before creating it. But it doesn't use the hibernate.default_schema value in doing so. Therefore it checks for the table in the entire database, which is a Bad Thing. I submitted a new bug on it yesterday. The issue has been raised before and was marked fixed, but it is not.

But the fact is that I do come up with the problem.
Hibernate does not insert into the default schema's table; it insert into the table which was first finded.

huh? hibernate does not do any insert via schemaupdate...

That it is!

You may not think it is a bug. But it causes trouble when the user of DB connection has DBA privilege and several user have tables of same name.
And I think my revised version is better.

max, SchemaUpdate doesn't do inserts, but when it sees the table from the other schema, it fails to create the table in the default schema. Later, when Hibernate tries to do anything with that table, it fails because it is using the default_schema property, and the table doesn't exist. This is definitely a problem when using Hibernate on Oracle databases. Multiple Oracle representatives have told me, "Just make sure and qualify all your table names with the schema." There is no other solution. I think they should have designed it differently, but since they didn't, I guess it becomes Hibernate's responsibility to support their quirky behavior. It currently does not do that since we are unable to specify a default schema that applies during SchemaUpdate. This is a major headache for those of use using SchemaUpdate. As a temporary solution for the project I'm on now, we've manually added the schema name to every table attribute in every mapping (like <class name="Foo" table="mySchema.foo">). This causes other issues, but ignorable ones for the moment.

Can we please get some help on this?[/b]

best help you can do is to create a testcase that fails and provide a patch that makes it work.

It's not a matter of a particular unit of code failing. It's about the environment in which it's running. Any call to SchemaUpdate will break if the conditions are right. As for a patch, are there instructions somewhere on how to create one? I've used CVS plenty (do you use CVS or SVN?), but never had to do patch files. I've identified two definite and two potential problem areas so far, and I hope to finish looking through the code and talking with our DBAs tomorrow.

cvs diff -u creates a patch or in eclipse just right click on Team and select "Create patch"