[Hibernate-JIRA] Created: (HHH-6361) Collection events may contain wrong stored snapshot after merging a detached entity into the persistencecontext
by Erik-Berndt Scheper (JIRA)
Collection events may contain wrong stored snapshot after merging a detached entity into the persistencecontext
---------------------------------------------------------------------------------------------------------------
Key: HHH-6361
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6361
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.6.5
Reporter: Erik-Berndt Scheper
Priority: Minor
After the merge process, driven by the {{DefaultMergeEventListener}}, it can happen that the Hibernate collection events contain references to an incorrect stored snapshot. This is both the case for the {{PersistentCollection}} and the {{CollectionEntry}}, as returned by {{session.getPersistenceContext().getCollectionEntry(persistentCollection)}}
By itself, this looks like a minor issue. However, this leads to severe problems when Envers is used. This bug causes HHH-6349, which results in inconsistent (invalid) audit trails and possibly AssertionFailures when the {{ValidityAuditStrategy}} is used.
I am pretty sure the same bug exists in the 4.0.0 Betas, since I have an Envers testcase for testng (3.6 branch) and junit4 (master) which both exhibit the same behaviour. However, I haven't looked in the changes in the merge process in 4.0.0 betas (compared to 3.6.x).
I am currently preparing a testcase for the Hibernate testsuite (complimentary to the Envers testcases) together with a suggested fix, but this takes a bit more work than I anticipated.
--
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
11 years, 5 months
[Hibernate-JIRA] Created: (HHH-7235) Support null NaturalId values in loadEntityIdByNaturalId query
by Guenther Demetz (JIRA)
Support null NaturalId values in loadEntityIdByNaturalId query
--------------------------------------------------------------
Key: HHH-7235
URL: https://hibernate.onjira.com/browse/HHH-7235
Project: Hibernate ORM
Issue Type: Improvement
Components: core
Affects Versions: 4.1.2, 4.1.1, 4.1.0
Reporter: Guenther Demetz
As it is allowed to persist and commit null naturalId values (for example null String values),
it would also be nice to can sucessful lookup for those values.
Currently the where-clause of the lookup-query does not consider the eventuality of null values, which in sql require an extra handling (using 'is' keyword instead of '=' sign).
The needed code change is simple, see pull request.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[Hibernate-JIRA] Created: (HHH-5436) different lock deepness for joined subclass
by kakusi kakusi (JIRA)
different lock deepness for joined subclass
-------------------------------------------
Key: HHH-5436
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5436
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.3.2, 3.2.5
Environment: Oracle 10g
Reporter: kakusi kakusi
Hi,
we use hibernate, oracle and pessimstic locking, to avoid concurrent modification through different threads.
This worked fine for a while. But now we sometimes get deadlocks. We analyzied and found the cause: we produced locks with different deepnesses for objects of type joined subclass.
An example for our kind of mapping:
{noformat} <class name="TraceObject" table="TraceObjects">
<cache usage="read-write" />
<id name="objectId" column="objectId" type="long">
<generator class="native">
<param name="sequence">TraceObjectsSeq</param>
</generator>
</id>
<timestamp name="dbVersionControl" />
...
</class>
<joined-subclass name="VehicleObject" table="VehicleObjects" extends="TraceObject">
<key column="id" />
...
</joined-subclass>{noformat}
Method:
{{session.get(Class clazz, Serializable id, LockMode lockMode);}}
Created Select-Statement:
{{SELECT traceobjec0_.objectId ... FROM TraceObjects traceobjec0_ LEFT OUTER JOIN VehicleObjects traceobjec0_3_ ON traceobjec0_.objectId=traceobjec0_3_.id WHERE traceobjec0_.objectId=? FOR UPDATE;}}
Effect:
This locks the relevant data in table TraceObjects and joined table VehicleObjects.
Method:
{{session.get(Class clazz, Serializable id);}}
{{session.lock(Object object, LockMode lockMode);}}
Created Select-Statement:
{{select traceobjec0_.objectId ... from TraceObjects traceobjec0_ left outer join VehicleObjects traceobjec0_3_ on traceobjec0_.objectId=traceobjec0_3_.id where traceobjec0_.objectId=?;}}
{{select objectId from TraceObjects where objectId =? for update;}}
Effect:
This only locks the relevant data in table TraceObjects.
We think this is a bug, because all techniques to lock should create the same lock type (only locking the parent table).
--
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
11 years, 5 months
[Hibernate-JIRA] Created: (HHH-5040) SQLQuery fails with auto-discovery of result set metadata and aliased columns
by Chris Wilson (JIRA)
SQLQuery fails with auto-discovery of result set metadata and aliased columns
-----------------------------------------------------------------------------
Key: HHH-5040
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5040
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.2
Environment: 3.3.2 GA, MySQL Connector/J 5.0.
Reporter: Chris Wilson
Attachments: HibernateSqlQueryAliasTest.java
Hibernate assumes that the column name returned by ResultSetMetaData#getColumnName(int) is the name it can use to extract the data from the ResultSet. However, if the SQLQuery uses column aliases, then this will fail here:
{code|title=Stack Trace}
org.hibernate.exception.SQLGrammarException: could not execute query
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:90)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
at org.hibernate.loader.Loader.doList(Loader.java:2235)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2129)
at org.hibernate.loader.Loader.list(Loader.java:2124)
at org.hibernate.loader.custom.CustomLoader.list(CustomLoader.java:312)
at org.hibernate.impl.SessionImpl.listCustomQuery(SessionImpl.java:1723)
at org.hibernate.impl.AbstractSessionImpl.list(AbstractSessionImpl.java:165)
at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java:175)
at org.wfp.rita.test.hibernate.HibernateSqlQueryAliasTest.testFailingWithAliases(HibernateSqlQueryAliasTest.java:45)
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.wfp.rita.test.base.HibernateTestBase.runTestMethod(HibernateTestBase.java:204)
at org.wfp.rita.test.base.HibernateTestBase.runTest(HibernateTestBase.java:117)
at junit.framework.TestCase.runBare(TestCase.java:130)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.sql.SQLException: Column 'id' not found.
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1075)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:989)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:984)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:929)
at com.mysql.jdbc.ResultSetImpl.findColumn(ResultSetImpl.java:1145)
at com.mysql.jdbc.ResultSetImpl.getInt(ResultSetImpl.java:2814)
at org.hibernate.type.IntegerType.get(IntegerType.java:51)
at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:184)
at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:210)
at org.hibernate.loader.custom.CustomLoader$ScalarResultColumnProcessor.extract(CustomLoader.java:497)
at org.hibernate.loader.custom.CustomLoader$ResultRowProcessor.buildResultRow(CustomLoader.java:443)
at org.hibernate.loader.custom.CustomLoader.getResultColumnOrRow(CustomLoader.java:340)
at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:629)
at org.hibernate.loader.Loader.doQuery(Loader.java:724)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259)
at org.hibernate.loader.Loader.doList(Loader.java:2232)
... 26 more
{code}
Hibernate appears to support auto-discovery of result set columns, notwithstanding bug
[HHH-436|http://opensource.atlassian.com/projects/hibernate/browse/HHH-436] which was closed as fixed. No QueryException is thrown if the returns of the query have not been defined.
Instead, SQLQueryImpl.verifyParameters() sets SQLQueryImpl.autodiscovertypes, which ends up in
QueryParameters.autodiscovertypes, which CustomLoader.doQuery() passes to CustomLoader.getResultSet(), which then calls CustomLoader.autoDiscoverTypes(), which calls
ScalarResultColumnProcessor.performDiscovery().
performDiscovery() calls ResultSetMetaData#getColumnName() to retrieve each column name from the result set, which ends up in CustomLoader.ResultRowProcessor, where ScalarResultColumnProcessor.extract() tries to use it to extract data from the result set. Because the name doesn't match the actual alias used in the result set, this fails with the exception given above.
[JDBC 4.0 Specification|http://jcp.org/aboutJava/communityprocess/final/jsr221/inde...] does not specify whether ResultSetMetaData.getColumnName() should return the name of the underlying column, or the name of the alias. It seems bizarre to me that it returns a value that cannot be passed to ResultSet.getObject(String). However, both MySQL and H2 take the position that we should call ResultSetMetaData.getColumnLabel() instead to get the name that can be used on the ResultSet:
* [MySQL bug 21379|http://bugs.mysql.com/bug.php?id=21379]
* [MySQL bug 21596|http://bugs.mysql.com/bug.php?id=21596]
* [H2 mailing list discussion|http://www.mail-archive.com/h2-database@googlegroups.com/msg00...]
The fix would appear to be modifying ScalarResultColumnProcessor.performDiscovery() (or CustomLoader.Metadata.getColumnName()) so that it calls getColumnLabel() instead of getColumnName(). The workaround is to explicitly specify column aliases with SQLQuery.addScalar().
Test case attached.
--
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
11 years, 5 months
[Hibernate-JIRA] Created: (HV-585) Order of validation messages is lost
by Gunther Schmidl (JIRA)
Order of validation messages is lost
------------------------------------
Key: HV-585
URL: https://hibernate.onjira.com/browse/HV-585
Project: Hibernate Validator
Issue Type: Improvement
Components: engine
Affects Versions: 4.3.0.Final
Environment: ---
Reporter: Gunther Schmidl
When adding validation messages, they are stored in an ArrayList. Later on, they are transferred to a HashSet, and finally to a String[] array. Naturally, putting them in a HashSet screws up the order of the messages, which may be important (for example, I have a "header" error message I wish to display first). Please consider changing the HashSet to a LinkedHashSet.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[Hibernate-JIRA] Created: (HHH-7227) distinct query in sql server when table contains text field
by Rafal Figas (JIRA)
distinct query in sql server when table contains text field
-----------------------------------------------------------
Key: HHH-7227
URL: https://hibernate.onjira.com/browse/HHH-7227
Project: Hibernate ORM
Issue Type: Improvement
Affects Versions: 3.6.9
Environment: SQL Server 2008, Microsoft SQL Server JDBC driver
Reporter: Rafal Figas
When SQL Server 2008 is used to run HQL query:
"select distinct a from A a"
and A contains field(s) mapped as type text exception is thrown:
com.microsoft.sqlserver.jdbc.SQLServerException: The text data type cannot be selected as DISTINCT because it is not comparable.
I don't know if it is even possible, but maybe it would be convenient to generate SQL query without distinct and then perform result transformation in cases where SQL Server dialect is used.
I've filed it as improvement, because it doesn't seem to be hibernate bug and there is workaround. Non-distinct results may be programmatically filtered out using org.hibernate.transform.DistinctResultTransformer.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[Hibernate-JIRA] Created: (HSEARCH-598) MassIndexer freezes when pool size is too low
by I D (JIRA)
MassIndexer freezes when pool size is too low
---------------------------------------------
Key: HSEARCH-598
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-598
Project: Hibernate Search
Issue Type: Bug
Components: massindexer
Affects Versions: 3.2.1
Environment: Hibernate Core 3.5.4, PostgreSQL 8.4.4
Reporter: I D
In our application we use db connection pooling at the servlet container level - Jetty instantiates a com.mchange.v2.c3p0.ComboPooledDataSource. We've disabled Hibernate's connection pooling to avoid multiple connection pools.
Soon after starting to use MassIndexer we noticed that it SOMETIMES freezes during operation - startAndWait() just hangs indefinitely. After some experimentation, we realized that during this freeze the connection pool is maxed out and all the 15 connections (c3p0's default value for maxPoolSize is 15) are active.
We therefore experimented with various values for maxPoolSize and found that 10 or less always seems to cause freezes, whereas 20 or more seems to work fine consistently. In between is a grey area, where the freeze occurs inconsistently (this grey area may of course extend to maxPoolSize<=10 and/or maxPoolSize>=20, since our tests only provide a partial statistical sample).
If this is expected behavior, the minimal pool size / number of required connections should be well documented.
--
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
11 years, 5 months