May 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3684) Sybase - Setting FetchMode.JOIN fails if there are 3 or more joins and at least one join involves a union

by Gail Badner (JIRA)

Sybase - Setting FetchMode.JOIN fails if there are 3 or more joins and at least one join involves a union --------------------------------------------------------------------------------------------------------- Key: HHH-3684 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3684 Project: Hibernate Core Issue Type: Bug Components: core Reporter: Gail Badner Assignee: Gail Badner This is reproduced by UnionSubclassTest.testUnionSubclassFetchMode().. This may be due to a bug in Sybase. A similar problem is discussed here: http://www.forumtopics.com/busobj/viewtopic.php?p=442226&sid=40bd96248c52... For the unit test mentioned above, changing: select ... from ( select ... from humans union select ... from employees ) this_ inner join locations location2_ on this_.location=location2_.id left outer join ( select ... from employees union select ... from humans union select ... from aliens ) beings3_ on location2_.id=beings3_.location : to: select ... from ( select ... from humans union select ... from employees ) this_ inner join (locations location2_ left outer join ( select ... from employees union select ... from humans union select ... from aliens ) beings3_ on location2_.id=beings3_.location) : on this_.location=location2_.id fixes the problem. This changer is similar to what is documented for a "right-nested outer join" at http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc32300.150.... -- 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
11
0 / 0

[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: (HSEARCH-749) Distribute helpers to understand Analyzers output

by Sanne Grinovero (JIRA)

Distribute helpers to understand Analyzers output ------------------------------------------------- Key: HSEARCH-749 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-749 Project: Hibernate Search Issue Type: New Feature Components: analyzer Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor Fix For: 4.0 As discusses on the mailing list, we should polish the API, document and distribute the AnalyzerUtils we use in some tests as people might find it useful to debug Analyzer definitions. -- 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
6
0 / 0

[Hibernate-JIRA] Created: (HV-465) Remove obsolete type parameter from MetaConstraint#validateConstraint()

by Gunnar Morling (JIRA)

Remove obsolete type parameter from MetaConstraint#validateConstraint() ----------------------------------------------------------------------- Key: HV-465 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-465 Project: Hibernate Validator Issue Type: Task Reporter: Gunnar Morling Fix For: 4.x The type parameter {{T}} of the method {{MetaConstraint#validateConstraint()}} is never used and should therefore be removed. -- 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
5
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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues May 2011