September 2011 - hibernate-issues

[Hibernate-JIRA] Created: (HHH-4055) make UpdateTimestampsCache pluggable, like QueryCache

by A. R. (JIRA)

make UpdateTimestampsCache pluggable, like QueryCache ----------------------------------------------------- Key: HHH-4055 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4055 Project: Hibernate Core Issue Type: Improvement Components: caching (L2) Affects Versions: 3.3.2 Environment: all Reporter: A. R. According to https://www.hibernate.org/213.html, one can plug-in one's own query cache using hibernate.cache.query_cache_factory, e.g. to chose a cache strategy that is not based on updateTimestamps. However, Hibernate's SessionFactoryImpl will always create an UpdateTimestampsCache if the Query Cache is enabled, even for custom Query Caches. This UpdateTimestampsCache then is always used in org.hibernate.engine.ActionQueue.execute() and afterTransactionCompletion(). Since the UpdateTimestampsCache is synchronized, this can cause bottlenecks when many threads change things (see http://tech.puredanger.com/2009/07/10/hibernate-query-cache/).. Please make the UpdateTimestampsCache also pluggable, so that one can truly and completely plug one's own Query Cache without using a Update-Timestamps or with a custom UpdateTimestampCache. -- 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

4
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2305) refresh throws exception when database has been altered with a delete

by Markus Heiden (JIRA)

refresh throws exception when database has been altered with a delete --------------------------------------------------------------------- Key: HHH-2305 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2305 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.1 Environment: Hibernate 3.2.1, Oracle 9.2 Reporter: Markus Heiden Attachments: hibernate.zip First I save an entity with a collection of cascading entities in it and flush. Then I delete these cascaded entities with a sql query. When I now do a refresh on the entity an exception is thrown, because the cascaded entities couldn't be found in the database. I expected these entities to be deleted from the (in memory) collection of the entity instead. Test case is attached. Stacktrace of test case: Hibernate: select c0_.id as id2_0_, c0_.c as c2_0_ from C c0_ where c0_.id=? org.hibernate.UnresolvableObjectException: No row with the given identifier exists: [hibernate.refresh.C#30003] at org.hibernate.UnresolvableObjectException.throwIfNull(UnresolvableObjectException.java:42) at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:126) at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:911) at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:894) at org.hibernate.engine.CascadingAction$4.cascade(CascadingAction.java:169) at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:216) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169) at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:296) at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:242) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:219) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169) at org.hibernate.engine.Cascade.cascade(Cascade.java:130) at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:99) at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:911) at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:894) at org.hibernate.engine.CascadingAction$4.cascade(CascadingAction.java:169) at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:216) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169) at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:296) at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:242) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:219) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169) at org.hibernate.engine.Cascade.cascade(Cascade.java:130) at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:99) at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:39) at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:902) at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:886) at hibernate.refresh.Test.main(Test.java:46) -- 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

5
5
0 / 0

[Hibernate-JIRA] Created: (HV-274) Write a programmatic mapping API for constraint declarations

by Emmanuel Bernard (JIRA)

Write a programmatic mapping API for constraint declarations ------------------------------------------------------------ Key: HV-274 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-274 Project: Hibernate Validator Issue Type: New Feature Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik -- 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

5
17
0 / 0

[Hibernate-JIRA] Created: (HHH-3360) Custom Oracle Batcher to allow batch updates for versioned data

by Manuel Dominguez Sarmiento (JIRA)

Custom Oracle Batcher to allow batch updates for versioned data --------------------------------------------------------------- Key: HHH-3360 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3360 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.3.0.CR1, 3.2.6, 3.2.5, 3.2.4.sp1, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2.0.ga Environment: Oracle 10g R1, 10g R2, 11g R1 (have not tried previous Oracle versions), 11g R1 drivers (older drivers should also work) Reporter: Manuel Dominguez Sarmiento Priority: Minor Attachments: C3P0OracleBatchingBatcher.java, C3P0OracleBatchingBatcherFactory.java, OracleBatchingBatcher.java, OracleBatchingBatcherFactory.java We have developed a custom Oracle Batcher which allows batching versioned data. The Oracle JDBC driver does not return update counts when using the standard JDBC 2.0 batching mechanism, however the proprietary Oracle batching mechanism allows obtaining the total batch row update count. The update counts are absolutely necessary to detect stale updates. Although it is not exactly the same, the total row update count is actually enough information to be able to batch versioned data and still detect stale updates. We'd like to contribute the attached files. They have a compile time dependency on Oracle JDBC. If this is not acceptable, it could be easily solved by using reflection. Another Batcher is provided for when the Oracle connection is being managed through c3p0 (a common deployment scenario). This has a compile time dependency on c3p0. A few "dirty" tricks were necessary to pull this off without patching other classes. Specifically, it was necessary to override Java private semantics to obtain BasicExpectation.expectedRowCount. This could be easily solved by adding an accessor method to the Expectation interface. There is one issue which we are not completely sure of, however so far we have not found any problems. When the Expectation is NONE, there is no way to check whether the total row count is correct or not, even if other batched updates do have expectations with expected row counts. Our understanding is that actually, since batching requires all statements to be of the same type (since the same PreparedStatement / CallableStatement is being used), then either ALL expectations will be NONE, or all will have an expected row count. We'd welcome comments from the Hibernate team. This could also be probably handled better by improving the Expectation interface. Oracle JDBC docs that explain the Oracle batching model: http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/oraperf.htm#... As expected, implementing this solution has resulted in drastical improvement in batch processing. -- 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

4
11
0 / 0

[Hibernate-JIRA] Created: (HHH-6463) hbm2ddl and Oracle DB: Found: number, expected: boolean

by Thomas (JIRA)

hbm2ddl and Oracle DB: Found: number, expected: boolean ------------------------------------------------------- Key: HHH-6463 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6463 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 4.0.0.Beta1 Reporter: Thomas As described in this forum topic: https://forum.hibernate.org/viewtopic.php?f=1&t=1011905&start=0 Since version 4 Hibernate (hbm2ddl) cannot map a boolean field in a JPA entity to a column with type number(1,0) in Oracle DB. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

6
12
0 / 0

[Hibernate-JIRA] Created: (ANN-644) @ManyToMany appears to ALWAYS generate a left outer join SQL

by Barry Davies (JIRA)

@ManyToMany appears to ALWAYS generate a left outer join SQL ------------------------------------------------------------ Key: ANN-644 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-644 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.3.0.ga Reporter: Barry Davies Priority: Minor Attachments: files.zip A collection mapping created using the @ManyToMany JPA annotation appears to create a left outer join SQL regardless of whether the joinColumn or inverseJoinColumn are marked nullable or not. This might be in error. Emmanuel asked for a JIRA issue to be created, so here we are. I have attached some files that can recreate what I believe to be the issue. The forum topic where this was brought up is: http://forum.hibernate.org/viewtopic.php?t=977936 -- 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
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3160) Support one-to-many list associations with constraints on both (owner_id, position) and (child_id)

by Gail Badner (JIRA)

Support one-to-many list associations with constraints on both (owner_id, position) and (child_id) -------------------------------------------------------------------------------------------------- Key: HHH-3160 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3160 Project: Hibernate3 Issue Type: Sub-task Reporter: Gail Badner Assignee: Gail Badner The logic used for removing entities from one-to-many list associations can cause ConstraintViolationException will be thrown if there are constraints on both (owner_id, position) and (child_id) in the "collection table". If the association is on a join table, the "collection table" is the join table; otherwise, the "collection table" is the child entity table.. Currently, SchemaExport does not put a constraint on (owner_id, position) when exporting one-to-many list associations on a foreign key. SchemaExport should be updated to also export this constraint. See HHH-1268 for a description of how to reproduce this issue. For one-to-many list associations on a foreign key, the workaround is to either define the constraint on (owner_id, position) in the child entity table as deferred. If this is not on option for a particular Dialect, the constraint on (owner_id, position) will have to be excluded. For a one-to-many list association on a join table, the workaround is to either define the constraint on (child_id) in the join table as deferred. If this is not on option for a particular Dialect, the constraint on (child_id) will have to be excluded. -- 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

4
6
0 / 0

[Hibernate-JIRA] Created: (HHH-6425) On Sybase ASE, insert a empty string '' to db, it stores it as single space ' '

by Ren Junyan (JIRA)

On Sybase ASE, insert a empty string '' to db, it stores it as single space ' ' ------------------------------------------------------------------------------- Key: HHH-6425 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6425 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.6.0 Environment: Hibernate 3.6.6, Sybase ASE15.5, JDK 1.6, Windows XP Reporter: Ren Junyan This is a defect of ASE, it fails the test below. testNewSerializableType(org.hibernate.test.lob.SerializableTypeTest) org.hibernate.type.SerializationException: could not deserialize at org.hibernate.util.SerializationHelper.doDeserialize(SerializationHelper.java:250) at org.hibernate.util.SerializationHelper.deserialize(SerializationHelper.java:306) at org.hibernate.type.descriptor.java.SerializableTypeDescriptor.fromBytes(SerializableTypeDescriptor.java:130) at org.hibernate.type.descriptor.java.SerializableTypeDescriptor.wrap(SerializableTypeDescriptor.java:116) at org.hibernate.type.descriptor.java.SerializableTypeDescriptor.wrap(SerializableTypeDescriptor.java:39) at org.hibernate.type.descriptor.sql.VarbinaryTypeDescriptor$2.doExtract(VarbinaryTypeDescriptor.java:62) at org.hibernate.type.descriptor.sql.BasicExtractor.extract(BasicExtractor.java:64) at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:253) at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:249) at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:229) at org.hibernate.type.AbstractStandardBasicType.hydrate(AbstractStandardBasicType.java:330) at org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2283) at org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1527) at org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1455) at org.hibernate.loader.Loader.getRow(Loader.java:1355) at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:611) at org.hibernate.loader.Loader.doQuery(Loader.java:829) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:274) at org.hibernate.loader.Loader.loadEntity(Loader.java:2037) at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:86) at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:76) at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3293) at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:496) at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:477) at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:227) at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:285) at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:152) at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:1090) at org.hibernate.impl.SessionImpl.get(SessionImpl.java:1005) at org.hibernate.impl.SessionImpl.get(SessionImpl.java:998) at org.hibernate.test.lob.SerializableTypeTest.testNewSerializableType(SerializableTypeTest.java:82) Caused by: java.io.EOFException at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2280) at java.io.ObjectInputStream$BlockDataInputStream.readUnsignedShort(ObjectInputStream.java:2761) at java.io.ObjectInputStream$BlockDataInputStream.readUTF(ObjectInputStream.java:2819) at java.io.ObjectInputStream.readString(ObjectInputStream.java:1598) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1319) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) at org.hibernate.util.SerializationHelper.doDeserialize(SerializationHelper.java:244) ... 60 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-853) Review OptimizerStrategy API

by Sanne Grinovero (JIRA)

Review OptimizerStrategy API ---------------------------- Key: HSEARCH-853 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-853 Project: Hibernate Search Issue Type: Improvement Reporter: Sanne Grinovero Fix For: 4.0.0.Alpha2 Not sure if we should still expose the IndexWriter to it. In all cases, interactions OptimizerStrategy <-> Workspace is currently tricky and should be simplified. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-829) Example IdHashShardingStrategy doesn't handle PurgeAll properly

by Sanne Grinovero (JIRA)

Example IdHashShardingStrategy doesn't handle PurgeAll properly --------------------------------------------------------------- Key: HSEARCH-829 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-829 Project: Hibernate Search Issue Type: Task Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.0 A PurgeAll command is handled by invoking shardStrategy.getDirectoryProvidersForDeletion(Class<?> entity, Serializable id, String idInString) and passing in null for the second and third arguments. IdHashShardingStrategy should handle this case and return all indexmanagers. Check the documentation to point this out as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

2
2
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues September 2011