December 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-6726) Oracle : map TextType to clob and ImageType to blob

by Strong Liu (JIRA)

Oracle : map TextType to clob and ImageType to blob --------------------------------------------------- Key: HHH-6726 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6726 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 4.0.0.CR4 Reporter: Strong Liu Assignee: Gail Badner now, TextType (LONGVARCHAR) is mapped to 'long' and ImageType (LONGVARBINARY) is mapped to 'long raw' but 'long' and 'long raw' are already deprecated in oracle, we should consider change this to : Types.LONGVARCHAR -- "clob" Types.LONGVARBINARY -- "blob" and this causes lots of tests fail on oracle due to 'org.hibernate.exception.GenericJDBCException: Stream has already been closed' Gail, I'm assigning this to you since you created those two types and much familiar that than me :), but feel free reassign it, thanks -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-6872) Test failures with hibernate.jdbc.batch_versioned_data=true

by Gail Badner (JIRA)

Test failures with hibernate.jdbc.batch_versioned_data=true ----------------------------------------------------------- Key: HHH-6872 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6872 Project: Hibernate Core Issue Type: Bug Components: testsuite Reporter: Gail Badner Assignee: Gail Badner The following tests fail with hibernate.jdbc.batch_versioned_data=true: org.hibernate.test.immutable.entitywithmutablecollection.inverse.VersionedEntityWithInverseManyToManyTest.testManyToManyCollectionOptimisticLockingWithUpdate org.hibernate.test.immutable.entitywithmutablecollection.inverse.VersionedEntityWithInverseOneToManyFailureExpectedTest.testOneToManyCollectionOptimisticLockingWithUpdate org.hibernate.test.immutable.entitywithmutablecollection.inverse.VersionedEntityWithInverseOneToManyJoinFailureExpectedTest.testOneToManyCollectionOptimisticLockingWithUpdate org.hibernate.test.immutable.entitywithmutablecollection.inverse.VersionedEntityWithInverseOneToManyJoinTest.testOneToManyCollectionOptimisticLockingWithUpdate org.hibernate.test.immutable.entitywithmutablecollection.inverse.VersionedEntityWithInverseOneToManyTest.testOneToManyCollectionOptimisticLockingWithUpdate org.hibernate.test.immutable.entitywithmutablecollection.noninverse.VersionedEntityWithNonInverseManyToManyTest.testManyToManyCollectionOptimisticLockingWithUpdate org.hibernate.test.immutable.entitywithmutablecollection.noninverse.VersionedEntityWithNonInverseOneToManyJoinTest.testOneToManyCollectionOptimisticLockingWithUpdate org.hibernate.test.immutable.entitywithmutablecollection.noninverse.VersionedEntityWithNonInverseOneToManyTest.testOneToManyCollectionOptimisticLockingWithUpdate These tests expect StaleObjectStateException to be thrown when an update fails due to an optimistic locking failure. When batching is used, StaleStateException is thrown instead because at the time that the batch statement executes, the entity name and ID are no longer available. The fix is to change the tests to expect StaleStateException and to check that the exception is a StaleObjectStateException instance when batching is not used. These tests only failed using Sybase because that is the only DB platform for which hibernate.jdbc.batch_versioned_data=true. I believe that hibernate.jdbc.batch_versioned_data=true should be used for all DB platforms being tested, except for Oracle. The version of Oracle JDBC used for testing still does not return row counts for batch updates. The src/test/resources hibernate.properties for each submodule will be updated to set hibernate.jdbc.batch_versioned_data=true. The setting will need to be set to false when testing with Oracle. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HV-513) URL validator rejects protocols the JVM does not know about

by Pasi Eronen (JIRA)

URL validator rejects protocols the JVM does not know about ----------------------------------------------------------- Key: HV-513 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-513 Project: Hibernate Validator Issue Type: Bug Components: validators Affects Versions: 4.2.0.Final, 4.1.0.Final Reporter: Pasi Eronen URLValidator uses java.net.URL(String) constructor to check whether an URL is valid. However, this constructor rejects a protocol unless the JVM has an URLStreamHandler for it. So perfectly valid URLs such as "ldap://localhost/ou=Foo" and "sip:alice@example.com" are rejected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-6864) Hibernate configuration issue with DB2Dialect

by Ramalingeswara Rao K V (JIRA)

Hibernate configuration issue with DB2Dialect --------------------------------------------- Key: HHH-6864 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6864 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.0 final Environment: Hibernate 3.0, JBoss 4.2.3 and DB2 luw 9.7 Reporter: Ramalingeswara Rao K V Our application is throwing the following error due to some incompatible issues with DB2Dialect. 2011-11-29 11:03:10,638 ERROR java.lang.UnsupportedOperationException: dialect does not support GUIDs at org.hibernate.dialect.Dialect.getSelectGUIDString(Dialect.java:754) at org.hibernate.id.GUIDGenerator.generate(GUIDGenerator.java:50) at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:122) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener.java:210) at org.hibernate.event.def.DefaultSaveEventListener.saveWithGeneratedOrRequestedId(DefaultSaveEventListener.java:56) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTransient(DefaultSaveOrUpdateEventListener.java:195) at org.hibernate.event.def.DefaultSaveEventListener.performSaveOrUpdate(DefaultSaveEventListener.java:50) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:93) The issue seems to be related to the following entry in hibernate xml files. <generator class="guid" /> *) We would like to know the common <generator> element which is compatible with ORACLE and DB2, etc. *) We would like to know how to separate the hbm configurations based on database (ORACLE, DB2, MYSQL, etc.). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-987) MassIndexer make Parameter SetFetchSize

by Gustavo (JIRA)

MassIndexer make Parameter SetFetchSize --------------------------------------- Key: HSEARCH-987 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-987 Project: Hibernate Search Issue Type: Improvement Components: massindexer Affects Versions: 3.4.0.Final Environment: mysql Reporter: Gustavo Priority: Minor I would like to use setFetchSize=1 in masssIndexer but currently it's hardcoded in org.hibernate.search.batchindexing.impl.IdentifierProducer at line 143. It would be nice to have all the possible parameters link: https://forum.hibernate.org/viewtopic.php?f=9&t=1013443&start=15 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
5
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

12 years, 5 months

2
1
0 / 0

[Hibernate-JIRA] Created: (OGM-113) Improve efficiency of EntityKey, RowKey ad Tuple

by Sanne Grinovero (JIRA)

Improve efficiency of EntityKey, RowKey ad Tuple ------------------------------------------------- Key: OGM-113 URL: http://opensource.atlassian.com/projects/hibernate/browse/OGM-113 Project: Hibernate OGM Issue Type: Improvement Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 3.0-next -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-6875) @OrderBy on @ElementCollection of basic type should "order by value"

by Christian Bauer (JIRA)

@OrderBy on @ElementCollection of basic type should "order by value" -------------------------------------------------------------------- Key: HHH-6875 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6875 Project: Hibernate Core Issue Type: Improvement Affects Versions: 4.0.0.CR7 Reporter: Christian Bauer Priority: Minor JPA 2.0 spec says: "The OrderBy annotation may be applied to an element collection. When OrderBy is applied to an element collection of basic type, the ordering will be by value of the basic objects and the property_or_field_name is not used." Hibernate currently ignores @OrderBy on @ElementCollection on e.g. List<String>. The order of elements is as returned by the database, undefined. The question is what "by value of the basic objects" means. In-memory String comparison, etc.? If it turns out "by value" means "whatever is returned by the database", this issue can be closed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-955) Property name for index manager slelection should be defined in Environment

by Hardy Ferentschik (JIRA)

Property name for index manager slelection should be defined in Environment --------------------------------------------------------------------------- Key: HSEARCH-955 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-955 Project: Hibernate Search Issue Type: Bug Affects Versions: 4.0.0.CR1 Reporter: Hardy Ferentschik Fix For: 4.0 The property hibernate.search.[default|<indexname>].indexmanager is not defined in the Environment class, but in _IndexManagerHolder_ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
2
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

12 years, 5 months

5
22
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues December 2011