August 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-5930) Remove hibernate-tools dependency from runtime scope if it's not needed

by Stevo Slavic (JIRA)

Remove hibernate-tools dependency from runtime scope if it's not needed ----------------------------------------------------------------------- Key: HHH-5930 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5930 Project: Hibernate Core Issue Type: Task Components: envers Affects Versions: 3.6.1 Reporter: Stevo Slavic See http://community.jboss.org/message/587294#587294 for more info. -- 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

14 years, 7 months

4
5
0 / 0

[Hibernate-JIRA] Created: (JPA-19) Many-to-Many: Unnecessary Table Join in generated SQL

by Bernard (JIRA)

Many-to-Many: Unnecessary Table Join in generated SQL ----------------------------------------------------- Key: JPA-19 URL: http://opensource.atlassian.com/projects/hibernate/browse/JPA-19 Project: Java Persistence API Issue Type: Bug Environment: java version "1.6.0_25" Java(TM) SE Runtime Environment (build 1.6.0_25-b06) Java HotSpot(TM) Client VM (build 20.0-b11, mixed mode, sharing) Reporter: Bernard Attachments: testcase.zip A simple JPQL query produces an unnecessary table join. Please refer to the attached testcase (NetBeans project). JPQL: select object(emp) from Employee emp , in(emp.projects) proj where proj = :project The generated native SQL is: select employee0_.id as id2_, employee0_.name as name2_ from Employee employee0_ inner join Employee_Project projects1_ on employee0_.id=projects1_.Employee_id inner join Project project2_ on projects1_.projects_id=project2_.id where project2_.id=? The generated SQL should have only one join, in other words the project table should not be included. Please refer to the attached testcase if this is useful - you need to set up the required libraries. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6592) Problem with the Envers revision numbering for multi-node applications

by Oleksandr Alesinskyy (JIRA)

Problem with the Envers revision numbering for multi-node applications ---------------------------------------------------------------------- Key: HHH-6592 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6592 Project: Hibernate Core Issue Type: Improvement Reporter: Oleksandr Alesinskyy Priority: Critical There is a problem with the revision numbering performed by Envers if an application is executed on the several nodes, namely: you either have to define a strictly serial ID generator for the Revision Entity such drastically impact a performance of all CRUD operations involving audited entities or forRevisionsOfEntity becomes broken, as it may occurs that a parent entity contains a child entity which was firstly created with the revisions higher then the last revision of the parent entity (as this "newer" revision has timestamp that predates a timestamp .of the "older" revision - and this may be not milliseconds but minutes). >From my point of view queries used by Envers shall take into account not so much revision numbers, as timestamps (at least as an alternative configurable mode). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-5789) Hibernate 3.5.4 doesn't build with OpenJDK 6b18-1.8.2 or greater

by Miguel Landaeta (JIRA)

Hibernate 3.5.4 doesn't build with OpenJDK 6b18-1.8.2 or greater ---------------------------------------------------------------- Key: HHH-5789 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5789 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.0, 3.6.0.CR2, 3.6.0.CR1, 3.5.6, 3.6.0.Beta4, 3.6.0.Beta3, 3.5.5, 3.6.0.Beta2, 3.6.0.Beta1, 3.5.4 Environment: Linux fiona 2.6.32-5-amd64 #1 SMP Thu Nov 25 18:02:11 UTC 2010 x86_64 GNU/Linux java version "1.6.0_18" OpenJDK Runtime Environment (IcedTea6 1.8.3) (6b18-1.8.3-2) OpenJDK 64-Bit Server VM (build 16.0-b13, mixed mode) Reporter: Miguel Landaeta Attachments: hibernate3_3.5.4.Final.buildlog Hi, In the BTS of Debian it was reported[1] that Hibernate 3.5.4 can not be built with recent versions of OpenJDK6. The compilation fails with a message similar to this one: [ERROR] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Compilation failure /build/user-libhibernate3-java_3.5.4.Final-4-amd64-X7BsRy/libhibernate3-java-3.5.4.Final/entitymanager/src/main/java/org/hibernate/ejb/criteria/path/AbstractPathImpl.java:[194,39] invalid inferred types for M; inferred type does not conform to declared bound(s) inferred: java.util.Map<K,V> bound(s): java.util.Map<capture#829 of ?,capture#332 of ?> This is due to more strict type inference checks in OpenJDK6 1.8.2 and greater. Debian is going to release a stable version of their distribution soon with OpenJDK6 1.8.3, so it's required to be able to compile Hibernate with that JDK version. Any help to fix this problem is very welcomed. The full build log is attached. Thanks, 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606295 -- 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

14 years, 7 months

4
5
0 / 0

[Hibernate-JIRA] Created: (HHH-6577) CUBRID Database Dialect

by Esen Sagynov (JIRA)

CUBRID Database Dialect ----------------------- Key: HHH-6577 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6577 Project: Hibernate Core Issue Type: Patch Components: core Affects Versions: 3.6.6, 3.6.5 Environment: Hibernate 3.6.x, CUBRID 8.3.x and later Reporter: Esen Sagynov Hi, I am the CUBRID open source RDBMS Project Manager. Our parent company NHN has extensively been using Hibernate in its services together with CUBRID Database Server. I have already communicated with Strong Liu who suggested to provide a patch for the Dialect Resolver. So, I have patched and submitted a [pull request|https://github.com/hibernate/hibernate-core/pull/153] at Github to branch 3.6, which includes: - New file added: CUBRIDDialect.java; - StandardDialectResolver extended. CUBRIDDialect class supports all versions of CUBRID starting from version 8.3.0 (8.3.0, 8.3.1, and current stable 8.4.0). If there is anything you would like me to change/add, please let me know. I will be glad to work on it. Regards, Esen Sagynov. CUBRID Project Manager. http://www.cubrid.org http://twitter.com/cubrid http://facebook.com/cubrid -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2225) NPE when eager fetching joined component with native SQL query

by Christian Bauer (JIRA)

NPE when eager fetching joined component with native SQL query -------------------------------------------------------------- Key: HHH-2225 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2225 Project: Hibernate3 Type: Bug Components: query-sql Versions: 3.2.0.ga Reporter: Christian Bauer Priority: Minor Item -> many-to-one -> User -> joined component -> billingAddress This: result = session.createSQLQuery("select {i.*}, {u.*}, {ba.*} from ITEM i" + " join USERS u on i.SELLER_ID = u.USER_ID" + " left join BILLING_ADDRESS ba on u.USER_ID = ba.USER_ID" + " where u.USERNAME = :uname") .addEntity("i", Item.class) .addJoin("u", "i.seller") .addJoin("ba", "u.billingAddress") fails with: java.lang.NullPointerException at org.hibernate.loader.DefaultEntityAliases.<init>(DefaultEntityAliases.java:37) at org.hibernate.loader.custom.sql.SQLQueryReturnProcessor.generateCustomReturns(SQLQueryReturnProcessor.java:283) at org.hibernate.loader.custom.sql.SQLCustomQuery.<init>(SQLCustomQuery.java:129) at org.hibernate.engine.query.NativeSQLQueryPlan.<init>(NativeSQLQueryPlan.java:43) at org.hibernate.engine.query.QueryPlanCache.getNativeSQLQueryPlan(QueryPlanCache.java:114) at org.hibernate.impl.AbstractSessionImpl.getNativeSQLQueryPlan(AbstractSessionImpl.java:137) at org.hibernate.impl.AbstractSessionImpl.list(AbstractSessionImpl.java:142) at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java: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

14 years, 7 months

15
24
0 / 0

[Hibernate-JIRA] Commented: (HHH-1780) negation of EXISTS in hql query does not work

by Strong Liu (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1780?page=c... ] Strong Liu commented on HHH-1780: --------------------------------- https://issues.jboss.org/browse/JBPAPP-6906 > negation of EXISTS in hql query does not work > --------------------------------------------- > > Key: HHH-1780 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1780 > Project: Hibernate Core > Issue Type: Bug > Affects Versions: 3.1.3, 3.2.0 cr1, 3.2.0.cr2 > Reporter: Marton Papp > Assignee: Strong Liu > Fix For: 4.0.0.Beta5, 3.6.7 > > Attachments: hibernate-HHH-1780-fix.patch, hibernate-HHH-1780-fix.patch, hibernate-HHH-1780-test.patch > > > Hello! > I think I found a bug in Hibernate, in class org.hibernate.hql.ast.HqlParser. > It is in the methtod: > public AST negateNode(AST x) > The switch lacks the node type: EXISTS. > The default negateNode() implementation in org.hibernate.hql.antlr.HqlBaseParser seems to be broken by me, since it does not actually inverts the node but returns a node that is inverted. Or, to be more exact, the negation of OR and AND types are buggy, since they seem to assume that negateNode() will change the node itself, and so they simply discard its return value. > I wish the branch for NOT was not commented out, since it would provide a workaround, but now i'm stuck. > Regards, > Marton -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Assigned: (HHH-1645) refresh with LockMode on an unitialized proxy does not work

by Gail Badner (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1645?page=c... ] Gail Badner reassigned HHH-1645: -------------------------------- Assignee: Gail Badner > refresh with LockMode on an unitialized proxy does not work > ----------------------------------------------------------- > > Key: HHH-1645 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1645 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.1.3, 4.0.0.CR1 > Reporter: Michael Kopp > Assignee: Gail Badner > Attachments: ProxyTest.java > > > the DefaultRefreshEventListener.onRefresh method checks if the object in question is an UninitializedProxy. > if ( source.getPersistenceContext().reassociateIfUninitializedProxy( event.getObject() ) ) return; > If this is the case it will reassociate it and return. > The problem is it will lose the LockMode. If the refresh call was actually done with LockMode.upgrade, the result should be a select for update, which does not happen in this case. > This is especially anoying as it depends on the state of the proxy: > - unitialized --> no for update > - initialzed --> select for update -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1645) refresh with LockMode on an unitialized proxy does not work

by Gail Badner (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1645?page=c... ] Gail Badner commented on HHH-1645: ---------------------------------- I've updated Laura's test to use LockOptions.UPGRADE and committed these tests to master. The failing tests in org.hibernate.test.proxy.ProxyTest are annotated with @FailureExpected. Thanks for the bug report and tests. > refresh with LockMode on an unitialized proxy does not work > ----------------------------------------------------------- > > Key: HHH-1645 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1645 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.1.3, 4.0.0.CR1 > Reporter: Michael Kopp > Attachments: ProxyTest.java > > > the DefaultRefreshEventListener.onRefresh method checks if the object in question is an UninitializedProxy. > if ( source.getPersistenceContext().reassociateIfUninitializedProxy( event.getObject() ) ) return; > If this is the case it will reassociate it and return. > The problem is it will lose the LockMode. If the refresh call was actually done with LockMode.upgrade, the result should be a select for update, which does not happen in this case. > This is especially anoying as it depends on the state of the proxy: > - unitialized --> no for update > - initialzed --> select for update -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1645) refresh with LockMode on an unitialized proxy does not work

by Gail Badner (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1645?page=c... ] Gail Badner updated HHH-1645: ----------------------------- Affects Version/s: 4.0.0.CR1 I've verified this reproduces in 4.0.0.CR1. > refresh with LockMode on an unitialized proxy does not work > ----------------------------------------------------------- > > Key: HHH-1645 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1645 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.1.3, 4.0.0.CR1 > Reporter: Michael Kopp > Attachments: ProxyTest.java > > > the DefaultRefreshEventListener.onRefresh method checks if the object in question is an UninitializedProxy. > if ( source.getPersistenceContext().reassociateIfUninitializedProxy( event.getObject() ) ) return; > If this is the case it will reassociate it and return. > The problem is it will lose the LockMode. If the refresh call was actually done with LockMode.upgrade, the result should be a select for update, which does not happen in this case. > This is especially anoying as it depends on the state of the proxy: > - unitialized --> no for update > - initialzed --> select for update -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
0
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 August 2011