December 2007 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2436) Incorrect SQL generation for some select statements with "group by"

by Joseph Marques (JIRA)

Incorrect SQL generation for some select statements with "group by" ------------------------------------------------------------------- Key: HHH-2436 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2436 Project: Hibernate3 Type: Bug Versions: 3.2.1 Reporter: Joseph Marques JPQL was: SELECT res.resourceType, count(res.resourceType) FROM ResourceGroup rg JOIN rg.resources res WHERE rg.id = :id GROUP BY res.resourceType It translated to: select resource2_.RESOURCE_TYPE_ID as col_0_0_, count(resource2_.RESOURCE_TYPE_ID) as col_1_0_, resourcety3_.ID as ID376_, resourcety3_.NAME as NAME376_, resourcety3_.DESCRIPTION as DESCRIPT3_376_, resourcety3_.CATEGORY as CATEGORY376_, resourcety3_.PLUGIN as PLUGIN376_, resourcety3_.CTIME as CTIME376_, resourcety3_.MTIME as MTIME376_, resourcety3_.PARENT_RESOURCE_TYPE_ID as PARENT8_376_, resourcety3_.PLUGIN_CONFIG_DEF_ID as PLUGIN9_376_, resourcety3_.RES_CONFIG_DEF_ID as RES10_376_ from public.ON_RESOURCE_GROUP resourcegr0_ inner join public.ON_RESOURCE_GROUP_RES_MAP resources1_ on resourcegr0_.ID=resources1_.RESOURCE_GROUP_ID inner join public.ON_RESOURCE resource2_ on resources1_.RESOURCE_ID=resource2_.ID inner join public.ON_RESOURCE_TYPE resourcety3_ on resource2_.RESOURCE_TYPE_ID=resourcety3_.ID where resourcegr0_.DTYPE in ( 'COMPATIBLE', 'MIXED' ) and resourcegr0_.ID=? group by resource2_.RESOURCE_TYPE_ID The message was: "ERROR main org.hibernate.util.JDBCExceptionReporter - ERROR: column "resourcety3_.id must appear in the GROUP BY caluse or be used in an aggregate function" My issue with this is that I only want to select a single object (along with the count of that object when grouped), but the generated SQL seems to be selecting two different objects - resource2_ and resourcety3_. The jdbc error message is perfectly correct; it's the translated SQL that seems a bit off. Maybe the JPQL syntax I want to use is not supported? Or perhaps I'm just doing something wrong? -- 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

18 years, 4 months

5
10
0 / 0

[Hibernate-JIRA] Created: (HHH-2536) NPE with custom SQL query and formula property

by Jörg Heinicke (JIRA)

NPE with custom SQL query and formula property ---------------------------------------------- Key: HHH-2536 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2536 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.1 Reporter: Jörg Heinicke Priority: Minor I have an object Balance which I map like the following (stripped): <class name="Balance" entity-name="Balance" table="BALANCE"> ... <property name="reportDate" column="report_date" type="..." not-null="true"/> <property name="year" formula="year(report_date)" type="..."/> </class> Now I have another object which is actually a cumulated view of the BALANCE table. For retrieving the values I use a custom SQL query. The mapping is almost the same (it is at least for the properties in question, but e.g. the ID mapping is different as it is a cumulated view). <class name="PaymentStatisticsData"> ... <property name="reportDate" column="report_date" type="..." not-null="true"/> <property name="year" formula="year(report_date)" type="..."/> <loader query-ref="paymentStatisticsData"/> </class> <sql-query name="paymentStatisticsData" read-only="true"> <return class="PaymentStatisticsData"/> select ... </sql-query> In theory there should be no difference, but the latter fails with the following NPE: Caused by: java.lang.NullPointerException at org.hibernate.loader.DefaultEntityAliases.intern(DefaultEntityAliases.java:133) at org.hibernate.loader.DefaultEntityAliases.getSuffixedPropertyAliases(DefaultEntityAliases.java:106) at org.hibernate.loader.DefaultEntityAliases.<init>(DefaultEntityAliases.java:52) at org.hibernate.loader.ColumnEntityAliases.<init>(ColumnEntityAliases.java:16) at org.hibernate.loader.custom.sql.SQLQueryReturnProcessor.generateCustomReturns(SQLQueryReturnProcessor.java:174) 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.SessionFactoryImpl.checkNamedQueries(SessionFactoryImpl.java:444) at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:351) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1291) Hope that's all information you need. Joerg -- 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

18 years, 4 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2627) Generated properties leak prepared statements in Hibernate 3.2.3 and higher.

by Michael Werle (JIRA)

Generated properties leak prepared statements in Hibernate 3.2.3 and higher. ---------------------------------------------------------------------------- Key: HHH-2627 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2627 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.4.sp1, 3.2.4, 3.2.3 Environment: Hibernate 3.2.2-4sp1, Oracle 10g (Oracle9Dialect) Reporter: Michael Werle Attachments: generated-lazy-statement-leak.patch The fix for HHH-2393, in combination with a change to AbstractBatcher 11333 to the Hibernate 3.2 branch (comment is "sybase testsuite"), created a PreparedStatement leak for generated properties. The reason is that, in revision 11333, org.hibernate.jdbc.AbstractBatcher#closeQueryStatement() was changed to check for the existence of the prepared statement in the statementsToClose collection instead of closing it unconditionally. The fix for HHH-2393 (revision 11117 in the Hibernate 3.2 branch) modified org.hibernate.persister.entity.AbstractEntityPersister#processGeneratedProperties() to make it use org.hibernate.jdbc.AbstractBatcher#closeQueryStatement() instead of org.hibernate.jdbc.AbstractBatcher#closeStatement(), which closes the statement without checking the statementsToClose collection. This is a problem because the statement in AbstractEntityPersister#processGeneratedProperties() is created with AbstractBatcher#prepareSelectStatement(), which does not add the statement to the statementsToClose collection. The attached patch to org.hibernate.persister.entity.AbstractEntityPersister changes processGeneratedProperties() back to using AbstractBatcher#closeStatement() and obtains the result set through ResultSet#executeQuery() instead of using the batcher. This fixes the prepared statement leak and matches other usages of AbstractBatcher#prepareSelectStatement(), which also avoid using the batcher for their result sets. It also makes the same change in AbstractEntityPersister#initializeLazyPropertiesFromDatastore() becuase it has exactly the same problem. No existing test cases are broken by the attached patch. I investigated ways to write a test case to explicitly verify that the result sets and statements were all being closed. However, because the counts in AbstractBatcher are private, and I do not know of a generic way to obtain counts through the JDBC API, I could not figure out a good way to do so without using reflection to access the private fields, which none of the existing test cases seem to do. The bug was discovered when running my web app against Oracle, which runs out of cursors when connections are leaked -- not exactly a practical way to write a test case, but sufficient to prove that the bug exists and is fixed by the patch. -- 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

18 years, 4 months

6
14
0 / 0

[Hibernate-JIRA] Commented: (HHH-229) Filter failes on many-to-many relations

by Diego Pires Plentz (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-229?page=co... ] Diego Pires Plentz commented on HHH-229: ---------------------------------------- Mark, the issue that Gavin is talking about is TODO-129. Could you provide a patch to solve this issue? > Filter failes on many-to-many relations > --------------------------------------- > > Key: HHH-229 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-229 > Project: Hibernate3 > Issue Type: Bug > Affects Versions: 3.1 rc3 > Environment: Hibernate3 RC1 > Reporter: Magnus Sandberg > Attachments: filterexample.zip > > > When adding a filter to a class or one-to-many relation the filtering happens as expected. When adding a filter to a many-to-many relation (and I guess other relations using a join table) the columns in the filter-condition are mapped on the join table and not the associated table - the result is failure with exception. -- 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

18 years, 4 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2944) References to commons-collections deprecated classes should be upgraded

by Stephen Kestle (JIRA)

References to commons-collections deprecated classes should be upgraded ----------------------------------------------------------------------- Key: HHH-2944 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2944 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.2.0.ga Reporter: Stephen Kestle As apache commons collections is moving to Java 5 and generics, all deprecated classes and methods will be removed (from the normal distribution). While these classes will still likely be available in a separately distributed jar, it is advisable to upgrade the usage of these. The only one I have come across is SequencedHashMap, which has been replaced by ListOrderedMap -- 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

18 years, 4 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2964) missing column name due to IndexNode.resolve calling queryableCollection.getIndexColumnNames()

by Kay Schubert (JIRA)

missing column name due to IndexNode.resolve calling queryableCollection.getIndexColumnNames() ---------------------------------------------------------------------------------------------- Key: HHH-2964 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2964 Project: Hibernate3 Issue Type: Bug Components: query-hql Affects Versions: 3.2.5, 3.2.4.sp1, 3.2.4, 3.2.3, 3.2.2, 3.2.1 Environment: hibernate-core 3.2.5, mysql 5 Reporter: Kay Schubert Attachments: IndexNode.patch Declared entities: @Entity class Book { @Id long id; @OneToMany(mappedBy = "id.book") @MapKey(name = "id.stationName") private Map<String, StationBooksCounter> stationBooksCounter; } @Embeddable class StationBooksCounterPk { String stationName; @ManyToOne(optional = false) Book book; } @Entity class StationBooksCounter { @EmbeddedId StationBooksCounterPk id; int count; } HQL: "from Book b where b.stationBooksCounter['key'].count > '0'" results in that SQL: "select ... from Book book0_ where exists ( select 1 from StationBooksCounter stationboo3_ where books0_.id=stationboo3_.book_id and stationboo3_.null = 'key' and and stationboo3_.count>'0')" (statements text have been deducted from analogous queries in actual application - I didn't actually compile that simplified test case, since I'm quite sure what the problem is) The "stationboo3_.null" is caused by IndexNode.resolve calling queryableCollection.getIndexColumnNames() to resolve the index column name. Here queryableCollection is an org.hibernate.persister.collection.AbstractCollectionPersister, and getIndexColumnNames() returns the String[] indexColumnNames, containing only one null element. I changed that to AbstractCollectionPersister.getIndexColumnNames(String tableAlias). It uses indexColumnNames as well as indexFormulaTemplates to build the SQL fragment. -- 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

18 years, 4 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2966) Create table fails for SchemaExport when a column is mapped again with insert="false" update="false"

by Varghese C V (JIRA)

Create table fails for SchemaExport when a column is mapped again with insert="false" update="false" ---------------------------------------------------------------------------------------------------- Key: HHH-2966 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2966 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Environment: Hibernate-3.2.5, Hsqldb-1.8.0.7 Reporter: Varghese C V Attachments: org.hibernate.mapping.Table.patch, repeated-column-mapping-test-case.zip AbstractCustomer mapping : <hibernate-mapping> <class name="org.hibernate.test.schemaexport.AbstractCustomer" abstract="true"> <id name="id" type="java.lang.String"> <column name="ID" length="20" /> <generator class="assigned" /> </id> <property name="countryCode" type="java.lang.String"> <column name="COUNTRY_CODE" length="2" /> </property> </class> </hibernate-mapping> CorporateCustomer mapping : <hibernate-mapping> <union-subclass name="org.hibernate.test.schemaexport.CorporateCustomer" extends="org.hibernate.test.schemaexport.AbstractCustomer"> <many-to-one name="country" class="org.hibernate.test.schemaexport.Country" insert="false" update="false"> <column name="COUNTRY_CODE" length="2" /> </many-to-one> </union-subclass> </hibernate-mapping> For these mappings, the ddl generated by SchemaExport contains the COUNTRY_CODE twice. Generated Sql create table CorporateCustomer ( ID varchar(20) not null, COUNTRY_CODE varchar(2), COUNTRY_CODE varchar(2), primary key (ID) ) I have attached a test case that reproduces this. I have also attached a patch to org.hibernate.mapping.Table to fix this problem. The patch is simply to skip the duplicate columns when the sql is being generated. Please do verify. -- 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

18 years, 4 months

2
1
0 / 0

[Hibernate-JIRA] Commented: (HBX-623) Add ability in reverse engineering config file to support cascades

by Jeffrey Williams (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-623?page=co... ] Jeffrey Williams commented on HBX-623: -------------------------------------- No I have not done any unit test. If you can point me in the right direction I could add one in. What package unittests for overridebinder in? Is there an example test I could follow. > Add ability in reverse engineering config file to support cascades > ------------------------------------------------------------------ > > Key: HBX-623 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-623 > Project: Hibernate Tools > Issue Type: Patch > Components: reverse-engineer > Affects Versions: 3.0beta2 > Environment: Hibernate Tools Beta 5 > Reporter: tony anecito > Priority: Critical > Fix For: 3.2.1 > > Attachments: many-to-one-attributes.diff > > > Please add ability to add cascade tag to resultant mapping files in the reveng file. Currently have to modifiy velocity template file -- 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

18 years, 4 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2973) drop table if exists SQL statement is wrong for PostgreSQL

by Carl Allain (JIRA)

drop table if exists SQL statement is wrong for PostgreSQL ---------------------------------------------------------- Key: HHH-2973 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2973 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.5 Environment: Windows XP, Postgres 8.2.5, Hibernate 3.2.5.ga Reporter: Carl Allain Priority: Minor I am using hibernate.connection.driver_class = org.postgresql.Driver When using hibernate.hbm2ddl.auto with create (to get a schema drop + a create) somewhere, Hibernate generates: 09:15:56,575 DEBUG SchemaExport:303 - drop table MESSAGES if exists 09:15:56,575 DEBUG SchemaExport:288 - Unsuccessful: drop table MESSAGES if exists 09:15:56,575 DEBUG SchemaExport:289 - ERROR: syntax error at or near "if" while the 8.2 posgresql doc says: DROP TABLE [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ] so it seems the "if exists" is at the wrong place for Postgresql (should be before the table name, not after) -- 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

18 years, 4 months

2
2
0 / 0

[Hibernate-JIRA] Commented: (HHH-1575) Expression.in on component object gives parameters til SQL in wrong order

by Diego Pires Plentz (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1575?page=c... ] Diego Pires Plentz commented on HHH-1575: ----------------------------------------- More info on linked issues. > Expression.in on component object gives parameters til SQL in wrong order > ------------------------------------------------------------------------- > > Key: HHH-1575 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1575 > Project: Hibernate3 > Issue Type: Bug > Components: query-criteria > Affects Versions: 3.1.2 > Environment: Oracle 9i, org.hibernate.criterion.InExpression > Reporter: Thierry Hermann > > The InExpression produces a statement like [where (key, station) in ((?,?),(?,?)...)] indeed. > but the parameter binding is wrong. > In fact if you look in org.hibernate.criterion.InExpression, getTypedValues() method (line: 53-54) both for loop should be inverted: > for ( int i=0; i<types.length; i++ ) > for ( int j=0; j<values.length; j++ ) > should become: > for ( int j=0; j<values.length; j++ ) > for ( int i=0; i<types.length; i++ ) -- 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

18 years, 4 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 December 2007