Re: [hibernate-dev] SAP HANA build failing for a while - does it reveal a bug?
Hi, These test failures are caused by the fix for https://hibernate.atlassian.net/browse/HHH-13104. There is some discussion in the ticket around how to best fix the test failures. Vlad has already opened a PR: https://github.com/hibernate/hibernate-orm/pull/2705 Best, Jonathan -Original Message- From: hibernate-dev-boun...@lists.jboss.org On Behalf Of Guillaume Smet Sent: Thursday, January 3, 2019 10:37 PM To: Hibernate Subject: [hibernate-dev] SAP HANA build failing for a while - does it reveal a bug? Hi, Since this build http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-hana-main/688/ , the SAP HANA build is failing consistently. With a lot of tests failing with: Caused by: org.hibernate.MappingException: Unable to build insert statement for table [Employee]: SAP HANA requires at least one value in insert value-list clause. at org.hibernate.sql.Insert.toStatementString(Insert.java:104) at org.hibernate.persister.entity.AbstractEntityPersister.generateIdentityInsertString(AbstractEntityPersister.java:2826) at org.hibernate.persister.entity.AbstractEntityPersister.doLateInit(AbstractEntityPersister.java:4147) at org.hibernate.persister.entity.AbstractEntityPersister.postInstantiate(AbstractEntityPersister.java:4220) at org.hibernate.metamodel.internal.MetamodelImpl.initialize(MetamodelImpl.java:257) at org.hibernate.internal.SessionFactoryImpl.(SessionFactoryImpl.java:294) at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:462) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:938) I wonder if we have broken something because I wouldn't expect so many tests to end with an empty insert? Could someone more familiar with these tests take a look at it? I don't think we need SAP HANA to check for the empty INSERT issue. Thanks. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate support for JDBC drivers targeting multiple JVM versions
I don’t have a specific link for the sharding feature. I just took a quick look at the JDBC 4.3 spec. The overview of changes lists the following changes regarding sharding: * Added support for Sharding. Sharding is a scaling technique in which data is horizontally partitioned across independent databases. * Addition of the java.sql.ShardigKey interface This interface is used to indicate that this object represents a Sharding Key. A ShardingKey instance is only guaranteed to be compatible with the data source instance that it was derived from. * Addition of the java.sql.ShardingKeyBuilder interface A builder created from a DataSource or XADataSource object, used to create a ShardingKey with sub-keys of supported data types. Just for completeness, there are other new interfaces that cause similar problems: * Addition of the java.sql.ConnectionBuilder interface A builder created from a DataSource object, used to establish a connection to the database that the data source object represents. * Addition of the javax.sql.XAConnectionBuilder interface A builder created from a XADataSource object, used to establish a connection to the database that the data source object represents. * Addition of the javax.sql.PooledConnectionBuilder interface A builder created from a PooledConnectionDataSource object, used to establish a connection to the database that the data source object represents. It looks like the HANA JDBC driver team will most likely go with multi-release JARs. If everything goes as planned we’ll also publish the driver on Maven Central soon. - Jonathan From: Steve Ebersole [mailto:st...@hibernate.org] Sent: Tuesday, March 13, 2018 4:21 PM To: Bregler, Jonathan <jonathan.breg...@sap.com> Cc: Sanne Grinovero <sa...@hibernate.org>; hibernate-dev@lists.jboss.org Subject: Re: [hibernate-dev] Hibernate support for JDBC drivers targeting multiple JVM versions Out of curiosity, do you have a link to this new java.sql.ShardingKey feature? Other than that, I agree with Sanne - multiple jars (with proper classifier once y'all publish your drivers) is the best option On Mon, Mar 12, 2018 at 11:35 AM Bregler, Jonathan <jonathan.breg...@sap.com<mailto:jonathan.breg...@sap.com>> wrote: Hi Sanne, Multi-release JARs sound promising. I'll forward your suggestion to the HANA JDBC driver team. Thanks, Jonathan -Original Message- From: sanne.grinov...@gmail.com<mailto:sanne.grinov...@gmail.com> [mailto:sanne.grinov...@gmail.com<mailto:sanne.grinov...@gmail.com>] On Behalf Of Sanne Grinovero Sent: Monday, March 12, 2018 4:45 PM To: Bregler, Jonathan <jonathan.breg...@sap.com<mailto:jonathan.breg...@sap.com>> Cc: hibernate-dev@lists.jboss.org<mailto:hibernate-dev@lists.jboss.org> Subject: Re: [hibernate-dev] Hibernate support for JDBC drivers targeting multiple JVM versions Hi Jonathan, personally this looks like an issue with the driver as class initialization could be triggered by a number of things, it's going to be hard to dodge them all, not least all containers and servers have their own peculiarities in how they load and wrap drivers and datasources; could you suggest the HANA JDBC team to release multi-release jars? That would be safer, and also avoid issues with other tools beyond Hibernate ORM. - http://openjdk.java.net/jeps/238 Thanks, Sanne On 12 March 2018 at 15:27, Bregler, Jonathan <jonathan.breg...@sap.com<mailto:jonathan.breg...@sap.com>> wrote: > Hi, > > in a recent version of the HANA JDBC driver the new JDBC 4.3 features that > came with Java 9 have been implemented. The driver itself is still compiled > for Java 7 (javac -target 1.7). So the driver should also be usable with a > JVM 7 or 8. This works as expected until Java reflection is used to > determine, for example, the existence of a method on the connection class. > Hibernate uses this approach in > org.hibernate.engine.jdbc.env.internal.DefaultSchemaNameResolver#determineAppropriateResolverDelegate > to determine if the connection class implements the #getSchema method. In > this case the JVM tries to load the entire connection class including the > non-existing new interface java.sql.ShardingKey. The result is a > java.lang.NoClassDefFoundError being thrown which isn't caught anywhere > causing the Hibernate bootstrapping process to fail. I've attached a sample > stack trace to this mail. > > Situations like this can also occur in other places, for example, when > getting a connection from a Hikari connection pool. > > My question is now how you think Hibernate should handle situations like > this. Do you see it as a JDBC driver issue? Should Hibernate ignore the error > and continue with a conservative guess if possible (e.g. assume that the > connection class doesn't implement #getSchema)? > > Thanks, >
Re: [hibernate-dev] Hibernate support for JDBC drivers targeting multiple JVM versions
Hi Sanne, Multi-release JARs sound promising. I'll forward your suggestion to the HANA JDBC driver team. Thanks, Jonathan -Original Message- From: sanne.grinov...@gmail.com [mailto:sanne.grinov...@gmail.com] On Behalf Of Sanne Grinovero Sent: Monday, March 12, 2018 4:45 PM To: Bregler, Jonathan <jonathan.breg...@sap.com> Cc: hibernate-dev@lists.jboss.org Subject: Re: [hibernate-dev] Hibernate support for JDBC drivers targeting multiple JVM versions Hi Jonathan, personally this looks like an issue with the driver as class initialization could be triggered by a number of things, it's going to be hard to dodge them all, not least all containers and servers have their own peculiarities in how they load and wrap drivers and datasources; could you suggest the HANA JDBC team to release multi-release jars? That would be safer, and also avoid issues with other tools beyond Hibernate ORM. - http://openjdk.java.net/jeps/238 Thanks, Sanne On 12 March 2018 at 15:27, Bregler, Jonathan <jonathan.breg...@sap.com> wrote: > Hi, > > in a recent version of the HANA JDBC driver the new JDBC 4.3 features that > came with Java 9 have been implemented. The driver itself is still compiled > for Java 7 (javac -target 1.7). So the driver should also be usable with a > JVM 7 or 8. This works as expected until Java reflection is used to > determine, for example, the existence of a method on the connection class. > Hibernate uses this approach in > org.hibernate.engine.jdbc.env.internal.DefaultSchemaNameResolver#determineAppropriateResolverDelegate > to determine if the connection class implements the #getSchema method. In > this case the JVM tries to load the entire connection class including the > non-existing new interface java.sql.ShardingKey. The result is a > java.lang.NoClassDefFoundError being thrown which isn't caught anywhere > causing the Hibernate bootstrapping process to fail. I've attached a sample > stack trace to this mail. > > Situations like this can also occur in other places, for example, when > getting a connection from a Hikari connection pool. > > My question is now how you think Hibernate should handle situations like > this. Do you see it as a JDBC driver issue? Should Hibernate ignore the error > and continue with a conservative guess if possible (e.g. assume that the > connection class doesn't implement #getSchema)? > > Thanks, > Jonathan > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate support for JDBC drivers targeting multiple JVM versions
Hi, in a recent version of the HANA JDBC driver the new JDBC 4.3 features that came with Java 9 have been implemented. The driver itself is still compiled for Java 7 (javac -target 1.7). So the driver should also be usable with a JVM 7 or 8. This works as expected until Java reflection is used to determine, for example, the existence of a method on the connection class. Hibernate uses this approach in org.hibernate.engine.jdbc.env.internal.DefaultSchemaNameResolver#determineAppropriateResolverDelegate to determine if the connection class implements the #getSchema method. In this case the JVM tries to load the entire connection class including the non-existing new interface java.sql.ShardingKey. The result is a java.lang.NoClassDefFoundError being thrown which isn't caught anywhere causing the Hibernate bootstrapping process to fail. I've attached a sample stack trace to this mail. Situations like this can also occur in other places, for example, when getting a connection from a Hikari connection pool. My question is now how you think Hibernate should handle situations like this. Do you see it as a JDBC driver issue? Should Hibernate ignore the error and continue with a conservative guess if possible (e.g. assume that the connection class doesn't implement #getSchema)? Thanks, Jonathan java.lang.NoClassDefFoundError: java/sql/ShardingKey at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2701) at java.lang.Class.privateGetMethodRecursive(Class.java:3048) at java.lang.Class.getMethod0(Class.java:3018) at java.lang.Class.privateGetMethodRecursive(Class.java:3058) at java.lang.Class.getMethod0(Class.java:3018) at java.lang.Class.getMethod(Class.java:1784) at org.hibernate.engine.jdbc.env.internal.DefaultSchemaNameResolver.determineAppropriateResolverDelegate(DefaultSchemaNameResolver.java:43) at org.hibernate.engine.jdbc.env.internal.DefaultSchemaNameResolver.resolveSchemaName(DefaultSchemaNameResolver.java:69) at org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentImpl.determineCurrentSchemaName(JdbcEnvironmentImpl.java:298) at org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentImpl.(JdbcEnvironmentImpl.java:232) at org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator.initiateService(JdbcEnvironmentInitiator.java:114) at org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator.initiateService(JdbcEnvironmentInitiator.java:1) at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.initiateService(StandardServiceRegistryImpl.java:88) at org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:258) at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:232) at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:209) at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:51) at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:94) at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:241) at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:209) at org.hibernate.boot.model.process.spi.MetadataBuildingProcess.handleTypes(MetadataBuildingProcess.java:356) at org.hibernate.boot.model.process.spi.MetadataBuildingProcess.complete(MetadataBuildingProcess.java:112) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.metadata(EntityManagerFactoryBuilderImpl.java:861) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:888) at org.hibernate.jpa.test.BaseEntityManagerFunctionalTestCase.buildEntityManagerFactory(BaseEntityManagerFunctionalTestCase.java:78) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at
Re: [hibernate-dev] Empty IN list support
Ok, thanks. For some reason I missed the Jira issue. - Jonathan From: Guillaume Smet [mailto:guillaume.s...@gmail.com] Sent: Friday, February 16, 2018 11:39 AM To: Vlad Mihalcea <mihalcea.v...@gmail.com> Cc: Bregler, Jonathan <jonathan.breg...@sap.com>; hibernate-dev@lists.jboss.org Subject: Re: [hibernate-dev] Empty IN list support See this related issue: https://hibernate.atlassian.net/browse/HHH-8091 On Fri, Feb 16, 2018 at 11:23 AM, Vlad Mihalcea <mihalcea.v...@gmail.com<mailto:mihalcea.v...@gmail.com>> wrote: I see that we are only using it for testing so that we can skip the: testEmptyInListQuery query on certain Dialects. We could use this info when rendering the JPQL/HQL queries to throw an exception before executing the query. Nevertheless, an exception will be thrown anyway even if we don't do it. Vlad On Fri, Feb 16, 2018 at 11:21 AM, Bregler, Jonathan < jonathan.breg...@sap.com<mailto:jonathan.breg...@sap.com>> wrote: > Hi, > > HANA doesn't support empty IN lists, so executing an HQL query that gets > transformed into a SQL query with an empty IN list results in a SQL parser > error on the database side. I noticed that the Dialect class already > defines a method called "supportsEmptyInList()" which according to the > Javadoc returns "True if empty in lists are supported; false otherwise". > However, this method doesn't seem to be used anywhere in the Hibernate > code. Is there a reason for that? > > Thanks, > Jonathan > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org<mailto:hibernate-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org<mailto:hibernate-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
