April 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-7277) Problem with expressions in criteria CASE WHEN OTHERWISE

by Srini (JIRA)

Problem with expressions in criteria CASE WHEN OTHERWISE --------------------------------------------------------- Key: HHH-7277 URL: https://hibernate.onjira.com/browse/HHH-7277 Project: Hibernate ORM Issue Type: Bug Components: query-criteria Affects Versions: 4.1.2, 3.6.1 Environment: Windows 7, JRE 1.6, JPA 2.0, MySQL, SQL Server 10.50.1600.1 Reporter: Srini JPA/Hibernate is not allowing to use an expression in WHEN and OTHERWISE clause of CASE statement. Following is criteria code, generated JPQL and the error it is throwing Case<String> sectorCase = cb.selectCase(); sectorCase.when(cb.notEqual(sectors.get(Sectors_.sectorName), Constants.ACCOUNT_TYPE_RESIDENTIAL), root.get(Customers_.customerName)). otherwise(cb.concat(root.get(Customers_.firstName), root.get(Customers_.lastName))); List<Selection<?>> selectCols = new ArrayList<Selection<?>>(); selectCols.add(root.get(Customers_.id).alias("id")); selectCols.add(sectorCase.alias("name")); cq.multiselect(selectCols); Error Details: Caused by: org.hibernate.hql.internal.ast.QuerySyntaxException: expecting "end", found '||' near line 1, column 171 [select distinct generatedAlias0.id, case when sector.sectorName<>:param0 then generatedAlias0.customerName else generatedAlias0.firstName || generatedAlias0.lastName end from com.abc.persistence.entity.Customers as generatedAlias0 left join generatedAlias0.sectors as sector order by case when sector.sectorName<>:param2 then generatedAlias0.customerName else generatedAlias0.firstName || generatedAlias0.lastName end asc] at org.hibernate.hql.internal.ast.QuerySyntaxException.convert(QuerySyntaxException.java:54) at org.hibernate.hql.internal.ast.QuerySyntaxException.convert(QuerySyntaxException.java:47) at org.hibernate.hql.internal.ast.ErrorCounter.throwQueryException(ErrorCounter.java:79) at org.hibernate.hql.internal.ast.QueryTranslatorImpl.parse(QueryTranslatorImpl.java:276) at org.hibernate.hql.internal.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:180) at org.hibernate.hql.internal.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:136) at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:101) at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:80) at org.hibernate.engine.query.spi.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:119) at org.hibernate.internal.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:215) at org.hibernate.internal.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:193) at org.hibernate.internal.SessionImpl.createQuery(SessionImpl.java:1649) at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:488) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-7215) NullPointerException in JtaTransaction when trying mark transaction for rollback

by Adi Sesha Reddy (JIRA)

NullPointerException in JtaTransaction when trying mark transaction for rollback -------------------------------------------------------------------------------- Key: HHH-7215 URL: https://hibernate.onjira.com/browse/HHH-7215 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.1.1, 4.1.0, 4.0.1 Reporter: Adi Sesha Reddy Attachments: BasicDrivingTest.java The issues is similar to this https://community.jboss.org/thread/197482. Notice 'hibernate.transaction.jta.platform' and 'hibernate.transaction.factory_class' properties. Here Hibernate is joining existing transaction. SynchronizationCallbackCoordinatorImpl tries to mark transaction for rollback when exception occurs, the chain of calls results in NullPointerException at TransactionCoordinatorImpl.setRollbackOnly(). To simulate the scenario, I modified BasicDrivingTest(https://github.com/hibernate/hibernate-orm/blob/master/h... which is attached with this issue(check line 76) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

4
9
0 / 0

[Hibernate-JIRA] Created: (HHH-7276) Regression allows entity to be looked up by previous natural id

by Steve Ebersole (JIRA)

Regression allows entity to be looked up by previous natural id ---------------------------------------------------------------- Key: HHH-7276 URL: https://hibernate.onjira.com/browse/HHH-7276 Project: Hibernate ORM Issue Type: Bug Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

1
1
0 / 0

[Hibernate-JIRA] Commented: (HHH-567) Duplicate "Order By" clause generated when using native sql statement with paging enabled

by Mark Adelsberger (JIRA)

[ https://hibernate.onjira.com/browse/HHH-567?page=com.atlassian.jira.plugi... ] Mark Adelsberger commented on HHH-567: -------------------------------------- (And as I misinterpreted the forum's date format, the issue is even older than I thought. Maybe best to disregard; sorry) > Duplicate "Order By" clause generated when using native sql statement with paging enabled > ----------------------------------------------------------------------------------------- > > Key: HHH-567 > URL: https://hibernate.onjira.com/browse/HHH-567 > Project: Hibernate ORM > Issue Type: Bug > Components: core > Affects Versions: 3.0.3 > Environment: Hibernate 3.0.3, RDBMS: DB2/NT, version: 07.02.0000 > Reporter: steven > > When a native sql is issued as following: > select person.oid as {personData.oid}, pn.firstName as {personData.firstName}, pn.lastName as {personData.lastName},person.dateOfBirth as {personData.birthDate}, person.gender as {personData.gender}, person.maritalStatus as {personData.maritalStatus}, pa.region as {personData.region}, pa.city as {personData.city}, pa.postalCode as {personData.zip} from Person person left outer join CPref2PostalAddress m on m.cprefId = person.defaultCPrefId left outer join PostalAddress pa on m.postalAddressId = pa.oid left outer join PersonName pn on pn.personId = person.oid where person.gender = :gender order by {personData.lastName} desc] > the generated sql is: > select * from ( select rownumber() over(order by lastName22_0_ desc) as rownumber_, person.oid as oid0_, pn.firstName as firstName22_0_, pn.lastName as lastName22_0_,person.dateOfBirth as birthDate22_0_, person.gender as gender22_0_, person.maritalStatus as maritalS7_22_0_, pa.region as region22_0_, pa.city as city22_0_, pa.postalCode as zip22_0_ from Person person left outer join CPref2PostalAddress m on m.cprefId = person.defaultCPrefId left outer join PostalAddress pa on m.contactPointId = pa.oid left outer join PersonName pn on pn.personId = person.oid order by lastName22_0_ desc ) as temp_ where rownumber_ <= ? > but the db2 complains that the second "order by" is illegal. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-567) Duplicate "Order By" clause generated when using native sql statement with paging enabled

by Mark Adelsberger (JIRA)

[ https://hibernate.onjira.com/browse/HHH-567?page=com.atlassian.jira.plugi... ] Mark Adelsberger commented on HHH-567: -------------------------------------- I realize this issue is a bit old, but maybe worth noting: prior to v9 DB2 really wouldn't let you put ORDER BY in a subselect. The issue is worded confusingly - it suggests that the appearance of ORDER BY at two paces in the query is the problem, but that is not the case. However, if your attempt to reproduce used a current version of DB2, then that's why you can't reproduce it; the query may "look" correct, but DB2 7 would reject it. > Duplicate "Order By" clause generated when using native sql statement with paging enabled > ----------------------------------------------------------------------------------------- > > Key: HHH-567 > URL: https://hibernate.onjira.com/browse/HHH-567 > Project: Hibernate ORM > Issue Type: Bug > Components: core > Affects Versions: 3.0.3 > Environment: Hibernate 3.0.3, RDBMS: DB2/NT, version: 07.02.0000 > Reporter: steven > > When a native sql is issued as following: > select person.oid as {personData.oid}, pn.firstName as {personData.firstName}, pn.lastName as {personData.lastName},person.dateOfBirth as {personData.birthDate}, person.gender as {personData.gender}, person.maritalStatus as {personData.maritalStatus}, pa.region as {personData.region}, pa.city as {personData.city}, pa.postalCode as {personData.zip} from Person person left outer join CPref2PostalAddress m on m.cprefId = person.defaultCPrefId left outer join PostalAddress pa on m.postalAddressId = pa.oid left outer join PersonName pn on pn.personId = person.oid where person.gender = :gender order by {personData.lastName} desc] > the generated sql is: > select * from ( select rownumber() over(order by lastName22_0_ desc) as rownumber_, person.oid as oid0_, pn.firstName as firstName22_0_, pn.lastName as lastName22_0_,person.dateOfBirth as birthDate22_0_, person.gender as gender22_0_, person.maritalStatus as maritalS7_22_0_, pa.region as region22_0_, pa.city as city22_0_, pa.postalCode as zip22_0_ from Person person left outer join CPref2PostalAddress m on m.cprefId = person.defaultCPrefId left outer join PostalAddress pa on m.contactPointId = pa.oid left outer join PersonName pn on pn.personId = person.oid order by lastName22_0_ desc ) as temp_ where rownumber_ <= ? > but the db2 complains that the second "order by" is illegal. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1512) Problem to lock a row in a DB2 database with LockMode UPGRADE

by Strong Liu (JIRA)

[ https://hibernate.onjira.com/browse/HHH-1512?page=com.atlassian.jira.plug... ] Strong Liu commented on HHH-1512: --------------------------------- had a quick chat with my friend, and he also things "with rs use and keep update locks" would be the best option in this case > Problem to lock a row in a DB2 database with LockMode UPGRADE > ------------------------------------------------------------- > > Key: HHH-1512 > URL: https://hibernate.onjira.com/browse/HHH-1512 > Project: Hibernate ORM > Issue Type: Bug > Components: core > Affects Versions: 3.1 > Environment: DB2 v8.2, Hibernate 3.1 and higher > Reporter: Peter Potthoff > Assignee: Steve Ebersole > Attachments: locks.txt > > Original Estimate: 1h > Remaining Estimate: 1h > > Using the LockMode UPGRADE to lock a row in the database, this will result in > a sql-statement: select ID from <schema>.<table> where ID =? and version =? for read only with rs > This statement produces a shared lock and cannot be used for pessimistic locking because > this kind of lock won't stop a concurrent thread from accessing the data. > The source of the class DB2Dialect.java was changed from release 1.34 to 1.35: > http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate3/src/org/hibern... > and from 1.33 to 1.34 > http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate3/src/org/hibern... > Please take a look at: HHH-378 and http://forum.hibernate.org/viewtopic.php?t=954639&highlight=db2+lock+upgrade -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1512) Problem to lock a row in a DB2 database with LockMode UPGRADE

by Strong Liu (JIRA)

[ https://hibernate.onjira.com/browse/HHH-1512?page=com.atlassian.jira.plug... ] Strong Liu commented on HHH-1512: --------------------------------- I guess you mean "rs" in the SQL above. then yes, it is correct > Problem to lock a row in a DB2 database with LockMode UPGRADE > ------------------------------------------------------------- > > Key: HHH-1512 > URL: https://hibernate.onjira.com/browse/HHH-1512 > Project: Hibernate ORM > Issue Type: Bug > Components: core > Affects Versions: 3.1 > Environment: DB2 v8.2, Hibernate 3.1 and higher > Reporter: Peter Potthoff > Assignee: Steve Ebersole > Attachments: locks.txt > > Original Estimate: 1h > Remaining Estimate: 1h > > Using the LockMode UPGRADE to lock a row in the database, this will result in > a sql-statement: select ID from <schema>.<table> where ID =? and version =? for read only with rs > This statement produces a shared lock and cannot be used for pessimistic locking because > this kind of lock won't stop a concurrent thread from accessing the data. > The source of the class DB2Dialect.java was changed from release 1.34 to 1.35: > http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate3/src/org/hibern... > and from 1.33 to 1.34 > http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate3/src/org/hibern... > Please take a look at: HHH-378 and http://forum.hibernate.org/viewtopic.php?t=954639&highlight=db2+lock+upgrade -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HV-562) Incorrect use of TCL to check visibility to JPA classes

by Sanjeeb Sahoo (JIRA)

Incorrect use of TCL to check visibility to JPA classes ------------------------------------------------------- Key: HV-562 URL: https://hibernate.onjira.com/browse/HV-562 Project: Hibernate Validator Issue Type: Bug Components: engine Affects Versions: 4.1.0.Final Reporter: Sanjeeb Sahoo Priority: Critical org.hibernate.validator.engine.resolver.DefaultTraversableResolver uses Thread's context class loader to check existence of PERSISTENCE_UTIL_CLASS_NAME as shown in the code below: The following code private void detectJPA() { try { loadClass( PERSISTENCE_UTIL_CLASS_NAME, this.getClass() ); log.debug( "Found {} on classpath.", PERSISTENCE_UTIL_CLASS_NAME ); } loadClass() first tries to use TCL to load the class. If TCL can't load, then it uses the class loader of the second argument to load the class. This is incorrect. It does not matter whether TCL can load PERSISTENCE_UTIL_CLASS_NAME, what matters is whether the class loader which is going to be used to load JPA_AWARE_TRAVERSABLE_RESOLVER_CLASS_NAME can load PERSISTENCE_UTIL_CLASS_NAME or not. Since HV-363 has now been fixed to use current class loader to load JPA_AWARE_TRAVERSABLE_RESOLVER_CLASS_NAME, the same class loader should also be used to detect existence of PERSISTENCE_UTIL_CLASS_NAME. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HV-538) Perform a profiling of the HV code in order to identify performance bottlenecks

by Gunnar Morling (JIRA)

Perform a profiling of the HV code in order to identify performance bottlenecks ------------------------------------------------------------------------------- Key: HV-538 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-538 Project: Hibernate Validator Issue Type: Improvement Components: engine Reporter: Gunnar Morling Fix For: 4.3.0.next Potential issues include: * handling of the {{Path}} API within the validation routine * creation of the descriptor model in {{BeanMetaDataImpl}} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

2
11
0 / 0

[Hibernate-JIRA] Created: (JPA-31) Simple JPQL with guarded null Parameter fails with Postgresql

by Bernard (JIRA)

Simple JPQL with guarded null Parameter fails with Postgresql ------------------------------------------------------------- Key: JPA-31 URL: https://hibernate.onjira.com/browse/JPA-31 Project: Java Persistence API Issue Type: Bug Affects Versions: 1.0.0 Environment: HIbernate 4.1.1 final, Postgresql driver 9.1-901-1.jdbc4 Reporter: Bernard Priority: Critical Attachments: NullParameterHibernatePostgresMaven.zip The attached tests contain a case that is similar to http://en.wikipedia.org/wiki/Java_Persistence_Query_Language#Examples that shows a JPQL query as follows: like SELECT a FROM Author a WHERE :lastName IS NULL OR LOWER(a.lastName) = :lastName Hibernate crashes in cases where the parameter values are null: ERROR: operator does not exist: character varying = bytea Hint: No operator matches the given name and argument type(s). You might need to add explicit type casts. The message originating from the engine or driver are not helpful because JPQL does not support type casts. I think the times are over where on application level one had to code different queries depending on whether a parameter value was null or not. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

1
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues April 2012