November 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3716) Sybase - null values for columns mapped as "boolean" are persisted as 0 (zero) instead of NULL

by Gail Badner (JIRA)

Sybase - null values for columns mapped as "boolean" are persisted as 0 (zero) instead of NULL ---------------------------------------------------------------------------------------------- Key: HHH-3716 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3716 Project: Hibernate Core Issue Type: Bug Components: core Environment: Sybase Reporter: Gail Badner Assignee: Gail Badner Fix For: 3.2.x, 3.3.x, 3.4 Null values for columns mapped as "boolean" are persisted as 0 (zero) instead of NULL. This happens because Hibernate persists a null Boolean value by calling: PreparedStatement.setNull( index, java.sql.Types.BIT ) The SQL code, java.sql.Types.BIT, is used because the Hibernate BooleanType defines its code as java.sql.Type.BIT. Sybase JDBC converts the null to 0, apparently because Sybase does not allow nullable bit columns. This can be reproduced using an annotations unit test, Java5FeaturesTest.testAutoboxing().. Sybase maps bit columns to tinyint, so when the unit test is executed, the column in the underlying table is actually of type tinyint, not bit. Sybase allows nullable tinyint columns, so there should be no problem persisting a null value as null. I've verified that changing the call to: PreparedStatement.setNull( index, java.sql.Types.TINYINT ) persists the null value without being converted to 0. -- 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

13 years, 1 month

3
8
0 / 0

[Hibernate-JIRA] Created: (HHH-5413) null values for columns mapped as "boolean" cause exception when saving entity with Sybase jdbc4

by Strong Liu (JIRA)

null values for columns mapped as "boolean" cause exception when saving entity with Sybase jdbc4 ------------------------------------------------------------------------------------------------ Key: HHH-5413 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5413 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.0.Beta1, 3.5.4, 3.5.3 Environment: Sybase jdbc4 Reporter: Strong Liu ASE doesn't allow 'null' value for 'BIT' datatype; While performing insert operation using jconn3.jar it permit you to have 'null' value, this 'null' value is converted into bit 0 by jconn3 & hence ASE doesn't throw any exception; But incase of jconn4.jar 'null' value is not converted into bit 0, hence jconn4 directly reports an exception for 'null' value(which is the expected correct behavior) Hibernate persists a null Boolean value by calling: PreparedStatement.setNull( index, java.sql.Types.BIT ) The SQL code, java.sql.Types.BIT, is used because the Hibernate BooleanType defines its code as java.sql.Type.BIT. This can be reproduced using an annotations unit test, Java5FeaturesTest.testAutoboxing().. Sybase maps bit columns to tinyint, so when the unit test is executed, the column in the underlying table is actually of type tinyint, not bit. Sybase allows nullable tinyint columns, so there should be no problem persisting a null value as null. I've verified that changing the call to: PreparedStatement.setNull( index, java.sql.Types.TINYINT ) persists the null value without being converted to 0. -- 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

13 years, 1 month

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-6795) unsupported Boolean type null value on Sybase causes hangs forever when doing bind parameter

by Strong Liu (JIRA)

unsupported Boolean type null value on Sybase causes hangs forever when doing bind parameter -------------------------------------------------------------------------------------------- Key: HHH-6795 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6795 Project: Hibernate Core Issue Type: Bug Reporter: Strong Liu _org.hibernate.test.annotations.entity.Java5FeaturesTest#testEnums_ when running this test, it calls org.hibernate.type.descriptor.sql.BasicBinder#bind to bind parameters to insert statement, since Bit.approved is null, then this "st.setNull( index, sqlDescriptor.getSqlType() );" is called, and sqlDescriptor.getSqlType() returns Types.BOOLEAN (16) stacktrace {code} Hibernate: insert into Bid (approved, description, editorsNote, note, DTYPE, id) values (?, ?, ?, ?, 'Bid', ?) 22:12:21,806 TRACE BasicBinder:3654 - binding parameter [1] as [BOOLEAN] - <null> 22:12:21,808 TRACE BasicBinder:3654 - binding parameter [2] as [VARCHAR] - My best one 22:12:21,814 TRACE EnumType:3674 - Binding {0} to parameter: 3 22:12:21,815 TRACE EnumType:3674 - Binding {0} to parameter: {1} 22:12:21,816 TRACE BasicBinder:3654 - binding parameter [5] as [INTEGER] - 1 22:12:21,817 DEBUG SqlExceptionHelper:3554 - JZ006: Caught IOException: java.io.IOException: JZ0SL: Unsupported SQL type 16. [n/a] java.sql.SQLException: JZ006: Caught IOException: java.io.IOException: JZ0SL: Unsupported SQL type 16. at com.sybase.jdbc4.jdbc.ErrorMessage.raiseError(Unknown Source) at com.sybase.jdbc4.jdbc.ErrorMessage.raiseErrorCheckDead(Unknown Source) at com.sybase.jdbc4.tds.Tds.a(Unknown Source) at com.sybase.jdbc4.tds.Tds.a(Unknown Source) at com.sybase.jdbc4.tds.Tds.dynamicExecute(Unknown Source) at com.sybase.jdbc4.jdbc.SybPreparedStatement.sendQuery(Unknown Source) at com.sybase.jdbc4.jdbc.SybStatement.executeUpdate(Unknown Source) at com.sybase.jdbc4.jdbc.SybPreparedStatement.executeUpdate(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:123) at org.hibernate.engine.jdbc.internal.proxy.AbstractProxyHandler.invoke(AbstractProxyHandler.java:81) at $Proxy17.executeUpdate(Unknown Source) at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:56) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2849) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3290) at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:80) at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:273) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:265) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:186) at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:337) at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50) at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1084) at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:319) at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:101) at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:175) at org.hibernate.test.annotations.entity.Java5FeaturesTest.testEnums(Java5FeaturesTest.java:78) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.hibernate.testing.junit4.ExtendedFrameworkMethod.invokeExplosively(ExtendedFrameworkMethod.java:63) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.hibernate.testing.junit4.FailureExpectedHandler.evaluate(FailureExpectedHandler.java:59) at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.hibernate.testing.junit4.BeforeClassCallbackHandler.evaluate(BeforeClassCallbackHandler.java:43) at org.hibernate.testing.junit4.AfterClassCallbackHandler.evaluate(AfterClassCallbackHandler.java:42) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.junit.runner.JUnitCore.run(JUnitCore.java:157) at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:71) at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:199) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) 22:12:21,827 WARN SqlExceptionHelper:3629 - SQL Error: 0, SQLState: JZ006 22:12:21,828 ERROR SqlExceptionHelper:3589 - JZ006: Caught IOException: java.io.IOException: JZ0SL: Unsupported SQL type 16. {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-6794) Share the same ReflectionManager amongst all Configurations in order to reduce SessionFactoryImpl memory footprint

by Julien Kronegg (JIRA)

Share the same ReflectionManager amongst all Configurations in order to reduce SessionFactoryImpl memory footprint ------------------------------------------------------------------------------------------------------------------ Key: HHH-6794 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6794 Project: Hibernate Core Issue Type: New Feature Components: core Affects Versions: 4.0.0.CR5, 3.6.8 Reporter: Julien Kronegg Priority: Minor h3. The problem: About 25% (i.e. about 50 MB in our case) of the memory used by Hibernate mappings is in the JavaReflectionManager instances. This occurs in the following configuration: - several persistence-units (5 in our case) - a lot of entities (about 286 entities) - each persistence-unit has the same entities (each persistence-unit has a different datasource) See also the Hibernate forum's [Memory usage after initializing SessionFactory|https://forum.hibernate.org/viewtopic.php?p=2449724#p2449724] h3. The cause: Basically, the ReflectionManager caches the reflection stuff (e.g. field->getter) to have faster processing. Each [org.hibernate.cfg.Configuration|https://fisheye2.atlassian.com/browse/~br...] has its own ReflectionManager instance. Thus, since each persistence-unit has the same entities, each ReflectionManager holds the same reflection data (but on different instances so that memory usage increase). h3. The solution: It would be nice if all Configuration share the same ReflectionManager (e.g. singleton) so that reflection data are cached only once. In the case of our setup, this would reduce Hibernate mappings memory usage by about 20%. This would require to make JavaReflectionManager thread-safe (which not currently the case, see HashMap and unsynchronized methods usage). h3. The workaround: We found that disabling Hibernate Validator in the persistence-unit reduced memory usage because the ReflectionManager is not used anymore: {code} <property name="hibernate.validator.apply_to_ddl" value="false"/> <property name="hibernate.validator.autoregister_listeners" value="false"/> {code} In our case, the memory usage decreased by about 100 MB. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6792) connection leaks due to service registry is not destroyed

by Strong Liu (JIRA)

connection leaks due to service registry is not destroyed ---------------------------------------------------------- Key: HHH-6792 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6792 Project: Hibernate Core Issue Type: Bug Reporter: Strong Liu Assignee: Strong Liu Fix For: 4.0.0.next we found there are lots of open connections during running test suite on sybase DB. this is caused by the _org.hibernate.service.spi.ServiceRegistryImplementor#destroy_ is not called after each test. a _org.hibernate.service.internal.StandardServiceRegistryImpl_ instance is shared between _SessionFactory_s, and for each _SessionFactory_, it has its own _org.hibernate.service.internal.SessionFactoryServiceRegistryImpl_ which inherits from the shared _org.hibernate.service.internal.StandardServiceRegistryImpl_ and the lifecycle of _org.hibernate.service.internal.SessionFactoryServiceRegistryImpl_ is as same as _SessionFactory_ (get destroyed when _SessionFactory_ closed) but the _org.hibernate.service.internal.StandardServiceRegistryImpl_ must be destroyed manually. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6791) tiny improvement, in favor of java auto-box instead of create new instance

by Strong Liu (JIRA)

tiny improvement, in favor of java auto-box instead of create new instance -------------------------------------------------------------------------- Key: HHH-6791 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6791 Project: Hibernate Core Issue Type: Task Reporter: Strong Liu Assignee: Strong Liu there are lots of legacy code which do not use auto box provided by jdk, but create new instances every time for each _Integer_, _Long_, _Short_ and so on. although there are some arguments that saying auto box in some cases may worse than create new Instance, but with auto-box, we can get benefit from jdk improvement -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6787) upgrade to JBoss Logging tools 1.0.0.CR3

by Strong Liu (JIRA)

upgrade to JBoss Logging tools 1.0.0.CR3 ---------------------------------------- Key: HHH-6787 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6787 Project: Hibernate Core Issue Type: Task Reporter: Strong Liu Assignee: Strong Liu Fix For: 4.0.0.next -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6786) DB2 v97 doesn't support define a boolean type column

by Strong Liu (JIRA)

DB2 v97 doesn't support define a boolean type column ---------------------------------------------------- Key: HHH-6786 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6786 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 4.0.0.CR5, 3.6.8 Reporter: Strong Liu Assignee: Strong Liu Fix For: 4.0.0.next, 3.6.next see this http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fc... for more details {quote} The Boolean data type cannot be used to define the data type of a column in a table or view. {quote} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-6788) org.hibernate.test.cut.CompositeUserTypeTest#testCustomColumnReadAndWrite fails on sybase

by Strong Liu (JIRA)

org.hibernate.test.cut.CompositeUserTypeTest#testCustomColumnReadAndWrite fails on sybase ----------------------------------------------------------------------------------------- Key: HHH-6788 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6788 Project: Hibernate Core Issue Type: Bug Environment: sybase ASE 15 JDBC4 driver Reporter: Strong Liu with jconn3, DYNAMIC_PREPARE default is false, but jconn4, it is true by default -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6785) Read-only query of entities with a collection of composite elements should not be dirty-checked.

by David Donn (JIRA)

Read-only query of entities with a collection of composite elements should not be dirty-checked. ------------------------------------------------------------------------------------------------ Key: HHH-6785 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6785 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.4 Reporter: David Donn I have an entity that includes a set and the set elements are mapped using composite-elements. Performing a read-only query for this entity should not result in any dirty checking. However the composite elements are being dirty checked. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues November 2011