March 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-5997) Collection actions contain non-transient references to session, entity, and collections causing inconsistencies after serialization

by Gail Badner (JIRA)

Collection actions contain non-transient references to session, entity, and collections causing inconsistencies after serialization ------------------------------------------------------------------------------------------------------------------------------------ Key: HHH-5997 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5997 Project: Hibernate Core Issue Type: Bug Reporter: Gail Badner Assignee: Gail Badner This is similar to HHH-5983, but for collection actions. -- 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

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-5086) "ambiguous column" SQL errors in Hibernate 3.5.0 Final

by dnalos (JIRA)

"ambiguous column" SQL errors in Hibernate 3.5.0 Final ------------------------------------------------------ Key: HHH-5086 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5086 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.0-Final Environment: Java JDK 1.6.0_19 Hibernate Core 3.5.0 Final hibernate-jpa-2.0-api-1.0.0.Final.jar mysql-connector-java-5.1.10-bin.jar Reporter: dnalos Attachments: HibernateAmbiguousTest.zip After update Hibernate Core to 3.5, we get some Exception like this: Column '_value' in field list is ambiguous (JDBCExceptionReporter.java:101) We create a testcase for you, and the Exception from the testcase: ERROR 15:39:28 0 Column '_value' in field list is ambiguous (JDBCExceptionReporter.java:101) org.hibernate.exception.ConstraintViolationException: could not load an entity: [Invoice#401] at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:96) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66) at org.hibernate.loader.Loader.loadEntity(Loader.java:1937) 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:3270) 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:1080) at org.hibernate.impl.SessionImpl.get(SessionImpl.java:997) at org.hibernate.impl.SessionImpl.get(SessionImpl.java:990) at HibernateAmbiguousTest.testAmbiguous(HibernateAmbiguousTest.java:55) 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.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Column '_value' in field list is ambiguous at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at com.mysql.jdbc.Util.handleNewInstance(Util.java:406) at com.mysql.jdbc.Util.getInstance(Util.java:381) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1015) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3558) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3490) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1959) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2109) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2648) at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2077) at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2228) at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeQuery(NewProxyPreparedStatement.java:76) at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:208) at org.hibernate.loader.Loader.getResultSet(Loader.java:1849) at org.hibernate.loader.Loader.doQuery(Loader.java:718) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:270) at org.hibernate.loader.Loader.loadEntity(Loader.java:1933) ... 34 more -- 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
10
0 / 0

[Hibernate-JIRA] Created: (HHH-5206) mapping TextType with outer join on oracle causes "Stream has already been closed" error

by Strong Liu (JIRA)

mapping TextType with outer join on oracle causes "Stream has already been closed" error ---------------------------------------------------------------------------------------- Key: HHH-5206 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5206 Project: Hibernate Core Issue Type: Bug Components: build Affects Versions: 3.5.1, 3.5.0-Final Reporter: Strong Liu Assignee: Gail Badner org.hibernate.test.onetoone.formula.OneToOneFormulaTest.testOneToOneFormula() fails on oracle {quote} http://www.jroller.com/agrebnev/entry/hibernate_dbms_portability_tips_tricks Instead BLOB I use "long raw". It is a VARBINARY hibernate type. Here I faced with another Oracle problem "java.sql.SQLException: Stream has already been closed" accessing long raw. The problem is that "The Oracle JDBC driver automatically closes any pending inputstreams whenever another database access is made". It means you should get binary data from result set before all other types. In terms of Hibernate the mapping of binary field should be last. And please keep in your mind that you should disable outer join fetching with class which contains this field. {quote} -- 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-5905) HQL "where in" queries consume near 100% CPU - possibly for hours

by Marcel Stör (JIRA)

HQL "where in" queries consume near 100% CPU - possibly for hours ----------------------------------------------------------------- Key: HHH-5905 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5905 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.5.6 Reporter: Marcel Stör Priority: Critical [Claim] The loop in ParameterParser.parse(String, ParameterParser$Recognizer) uses 100% CPU core per thread that executes it since it iterates over a string char by char and calling string operations in the loop. [Java client] Query query = getEntityManager().createQuery("select articleNumber from Article where articleNumber in (:articleNumbers)"); query.setParameter("articleNumbers", articleNumbers); List<ArticleNumber> filteredArticleNumbers = (List<ArticleNumber>) query.getResultList(); [Stacktrace of involved classes/methods] ParameterParser.parse(String, ParameterParser$Recognizer) line: 88 ParamLocationRecognizer.parseLocations(String) line: 75 HQLQueryPlan.buildParameterMetadata(ParameterTranslations, String) line: 290 HQLQueryPlan.<init>(String, String, boolean, Map, SessionFactoryImplementor) line: 121 HQLQueryPlan.<init>(String, boolean, Map, SessionFactoryImplementor) line: 80 QueryPlanCache.getHQLQueryPlan(String, boolean, Map) line: 98 SessionImpl(AbstractSessionImpl).getHQLQueryPlan(String, boolean) line: 156 SessionImpl.list(String, QueryParameters) line: 1250 QueryImpl.list() line: 102 QueryImpl<X>.getResultList() line: 241 [Observations] QueryImpl#list() calls SessionImpl#list(String, QueryParameters) passing the *expanded* query: return getSession().list(expandParameterLists(namedParams), getQueryParameters(namedParams)); Hence, what is passed to SessionImpl#list(String, QueryParameters) in my case is something like: select articleNumber from Article where articleNumber in (:articleNumbers0_, :articleNumbers1_, :articleNumbers2_, :articleNumbers3_, :articleNumbers4_, :articleNumbers5_, :articleNumbers6_, Now imagine how long that query string is when the "where in" query has a few thousand article numbers. org.hibernate.engine.query.ParameterParser.parse(String, Recognizer) then iterates over each character in the query string and calls StringHelper.firstIndexOfChar() for each named parameter. Even on fast servers this operation may easily take half an hour or more (mind you it's a blocking call!) if the expanded query string has a few million characters. I don't know Hibernate well enough to propose a fix but "where in" with Hibernate is an absolute no-go as it is right now. We had switch all our "where in" queries to native :-( -- 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
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-678) @NumericField does not work with BigDecimal types (and others?)

by Nick Fenwick (JIRA)

@NumericField does not work with BigDecimal types (and others?) --------------------------------------------------------------- Key: HSEARCH-678 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-678 Project: Hibernate Search Issue Type: Bug Affects Versions: 3.3.0.Final Environment: Hibernate 3.6.0, MySQL 5.1.52, Fedora Core 14 Reporter: Nick Fenwick This is my first JIRA so please help me assigns its Component above correctly. My first attempt to use BigDecimal ran into trouble trying to use the new @NumericField annotation. The SessionFactory fails to create an instance of the session. The code: {{ @Column(name="val") @Field(name="val", index=Index.UN_TOKENIZED, store=Store.YES) @NumericField private BigDecimal val; }} Results in the exception: {{ Exception in thread "main" java.lang.ExceptionInInitializerError [cut] Caused by: org.hibernate.HibernateException: could not init listeners [cut] Caused by: org.hibernate.search.SearchException: Unable to guess FieldBridge for val at org.hibernate.search.bridge.BridgeFactory.guessType(BridgeFactory.java:250) at org.hibernate.search.engine.AbstractDocumentBuilder.bindFieldAnnotation(AbstractDocumentBuilder.java:690) at org.hibernate.search.engine.AbstractDocumentBuilder.checkForField(AbstractDocumentBuilder.java:564) [cut] }} Taking out the @NumericField allows the session to start up successfully. I will attempt to make a test case but I'm having local build env issues. 'mvn clean install' of a fresh hibernate search git checkout is taking an incredibly long time (an hour for the first 10 or so .pom files?) so I may be several hours or days over this trivial task. -- 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
22
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-461) Improve support for all language specific snowball Analyzers in Lucene/contrib

by Sanne Grinovero (JIRA)

Improve support for all language specific snowball Analyzers in Lucene/contrib ------------------------------------------------------------------------------ Key: HSEARCH-461 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-461 Project: Hibernate Search Issue Type: Improvement Reporter: Sanne Grinovero Fix For: 3.3.0 For Lucene 3.1 Robert Muir did a great job of standardazing and cleaning Analyzers in contrib with many languages support (wrapping snowball analyzers); I'd like to look into having some helper in Hibernate Search in setting them up all to be available as analyzers and couple to entities in some clever way. -- 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-5409) bag and idbag should implement equals() and hashCode() the same way as other collections

by Dmitry Katsubo (JIRA)

bag and idbag should implement equals() and hashCode() the same way as other collections ---------------------------------------------------------------------------------------- Key: HHH-5409 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5409 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Reporter: Dmitry Katsubo bags/idbags behave in inconsistent way in comparison to set/list/map in respect to {{equals()}} and {{hashCode()}}. In {{[PersistentBag.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentBag.java?r=HEAD#l510]}} {{equals()}} and {{hashCode()}} methods are commented and in {{[PersistentIdentifierBag.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentIdentifierBag.java?r=HEAD]}} not present. {{[PersistentMap.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentMap.java?r=HEAD#l449]}}, {{[PersistentSet.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentSet.java?r=HEAD#l428]}}, {{[PersistentList.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentList.java?r=HEAD#l484]}} however implement {{equals()}} and {{hashCode()}} methods correctly. The intention of this is clear: to avoid loading of the lazy collection on simple {{equals()}} call. * I think that it is a task for the end application to handle lazy collections as it is aware about this situation. * If there is a strong demand of not loading collections on {{equals()}} call for some applications, I suggest to make this behaviour configurable via additional attribute in XML mapping for all collections. * The behaviour should be documented as suggested in HHH-1642. I personally spend hours debugging before I understood why lists behave differently from bags. Probably relative issues: * HHH-3771 ({{equals()}} for lazy loaded objects) * HHH-1642 ({{equals()}} for {{[AbstractPersistentCollection.SetProxy|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/AbstractPersistentCollection.java?r=HEAD#l636]}}) -- 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: (HSEARCH-56) Updating a collection does not reindex

by Emmanuel Bernard (JIRA)

Updating a collection does not reindex -------------------------------------- Key: HSEARCH-56 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-56 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.0.0.beta1 Reporter: Emmanuel Bernard -- 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
8
0 / 0

[Hibernate-JIRA] Created: (HHH-6068) JPA-specified default schema ignored for Hibernate sequences

by Laird Nelson (JIRA)

JPA-specified default schema ignored for Hibernate sequences ------------------------------------------------------------ Key: HHH-6068 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6068 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.2, 3.6.1, 3.6.0, 3.5.6 Reporter: Laird Nelson The <persistence-unit-defaults> element in a JPA 2.0-compliant orm.xml file lets you specify what you would like to have used as the default schema when none is specified elsewhere. Hibernate ignores this element when referring to its own internal sequence, "hibernate_sequence". I suspect it also ignores the default catalog element as well. The only workaround is to use the hibernate-specific hibernate.default_schema property. IMHO Hibernate should honor the JPA orm.xml value if it is present. -- 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
14
0 / 0

[Hibernate-JIRA] Created: (HHH-5992) A query fails to return correct results silently

by Tom Ross (JIRA)

A query fails to return correct results silently ------------------------------------------------ Key: HHH-5992 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5992 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.2 Environment: JBoss EAP 5.1 Reporter: Tom Ross The following query fails silently to return a correct result select v1.username, v2.username from user_ety v1, user_ety v2 where v1.username = '1' and v2.username = '2'. It returns one row with "1,1" instead of one row with "1,2". The query works with pre JPA CMP EJBs (ver 2.1) but fails when moved to JPA based persistence. This failure is very dangerous since it is silent and without manually checking data it is impossible to determine if a correct set is returned. The workaround is to use aliases and modify the query so it looks like that: select v1.username as username1, v2.username as username2 from user_ety v1, user_ety v2 where v1.username = '1' and v2.username = '2'. -- 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
9
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues March 2011