| Using JPA 2.0 under EAP 6.4 (Hibernate 4.x) everything worked fine.
Client has single-tennancy connection provider with a set (non-default by user-name) schema in the database. This is being set as a config property in persistence.xml as:
<property name="hibernate.default_schema" value="foobar"/> Upon attempting to deploy to EAP 7.0.0, hbm2ddl verification fails claiming missing tables. Initialization shows that static SQL is being generated with the proper schema name prefixed to table names. After that, when hbm2ddl kicks off, here's the code-path I see happening which I believe is leading to the 'null' schema / catalog names. org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentImpl.java:255 - The 'determineCurrentSchemaImpl' is being invoked, which is in turn invoking 'resolveSchemaName' on the default schema name resolver (being provided by inheriting all the way up to Dialect itself). The default schemaname resolver is invoking the java1.7 Connection.getSchema() method, however, the driver I'm using doesn't implement it!  This results in SchemaNameResolverJava17Delegate throwing the HibernateException on line 75. (I'm looking at the 5.0.9 code here) regarding it's "Unable to invoke Connection#getSchema method via reflection"). This exception is caught, by the JdbcEnvironmentImpl.java which then returns 'null' for the schema name. (which is not the right thing to do). In trying to figure out what I'd like to see done here.... 1.) I don't think we should be interrogating the current connection state to see what schema is active if there's a default_schema specified in the configuration properties. But I'm also not the hibernate architects, so I'm sure you've got a good reason for doing this. That said, I've seen several Hibernate apps in the last year (at this client, no less) which use / reference schemas other than the default schema for the connected user. Expecting hbm2ddl to resolve all tables based on the connections 'current schema' would result in inaccurate validate behavior, as it would be trying to validate the tables exist in the current schema, not the one we wanted to be referenced. 2.) I can see how I can easily replace the current schema name resolver based on "hibernate.schema_name_resolver", but why should I have to? This configuration worked properly in 4.x. This will have to be my work-around going forward until something is done about.... 3.) In the case of silently catching the Exception on JdbcEnvironmentImpl.java:278, this is really sorta shoddy. Why doesn't it return the value of the default_schema property instead of null? At least then, the verify would be successful and my tables would be properly detected. To to clarify what I think really ought to be going on inside the DefaultSchemaNameResolver..... 1.) Try JDK 1.7 Connection.getSchema. if it isn't available (or doesn't work when you try it!!)
2.) Fallback to the SchemaNameResolverFallbackDelegate (using Dialect.getCurrentSchemaCommand()). If The Dialect doesn't supply a getCurrentSchemaCommand() then
3.) Return the value of hibernate.default_schema If all of that gets through and it returns 'null', then you'll have the same behavior I'm currently seeing (where it's not using a schema name) which would seem appropriate. Perhaps the case could be made that default_schema should be the first thing returned (since you're effectively forcing it) but I think of that more as a 'fallback'. Either way, it's very unsettling to see that the code creating the default static queries for each Entity type is not using the same code paths as the verification code from hbm2ddl. |
