August 2007 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2289) CLONE -Support new MySQL 5.0.12 join syntax

by Peter Lundberg (JIRA)

CLONE -Support new MySQL 5.0.12 join syntax ------------------------------------------- Key: HHH-2289 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2289 Project: Hibernate3 Type: New Feature Components: query-sql Versions: 3.1.2 Reporter: Peter Lundberg http://dev.mysql.com/doc/refman/5.0/en/join.html "Beginning with MySQL 5.0.12, natural joins and joins with USING, including outer join variants, are processed according to the SQL:2003 standard. These changes make MySQL more compliant with standard SQL. However, they can result in different output columns for some joins. Also, some queries that appeared to work correctly in older versions must be rewritten to comply with the standard. The following list provides more detail about several effects of the 5.0.12 change in join processing. The term "previously" means "prior to MySQL 5.0.12." Using 5.0.18 and hibernate 3.1.2, hibernate is not producing the correct join syntax for the latest versions of mysql. For example: FROM tableA AS A, tableB AS B INNER JOIN tableC AS C ON A.field1 = C.field2 The above fails, because the B JOIN C is evaluated before the A alias has been created. The solution is to use parentheses to force an order of evaluation: FROM (tableA AS A, tableB AS B) INNER JOIN tableC AS C ON A.field1 = C.field2 -- 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

17 years, 5 months

2
1
0 / 0

[Hibernate-JIRA] Commented: (HHH-1786) JTASessionContext.CleanupSynch does not remove sessions from currentSessionMap

by Reggie Riser (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1786?page=c... ] Reggie Riser commented on HHH-1786: ----------------------------------- We're an IBM partner, so we escalated this issue up the IBM support chain until we got feedback from the WebSphere Transaction Architect. His take is that WebSphere is complying with the J2EE spec in this instance, and that this problem should definitely not be considered a bug in WebSphere. He said the workaround was OK, and suggested that we lobby Hibernate to integrate it into its codebase. We've implemented the workaround in our application, but obviously would prefer it be a part of Hibernate proper. Is there any chance of this happening? Don't shoot the messenger. We're just developers caught in the middle. > JTASessionContext.CleanupSynch does not remove sessions from currentSessionMap > ------------------------------------------------------------------------------ > > Key: HHH-1786 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1786 > Project: Hibernate3 > Issue Type: Improvement > Affects Versions: 3.1.2 > Environment: IBM WebSphere 6.0.2.7, Hibernate CVS snapshot from 2006-02-24 > Reporter: Tomi Szabo > Attachments: JTASessionContext.java, WebSphereExtendedJTATransactionLookup.java, WebSphereExtendedJTATransactionLookup.patch.txt > > > We are using JTASessionContext, CMTTransaction and WebSphereExtendedJTATransactionLookup. We have experienced some memmory leak problems and after closer inspection we have found that Hibernate sessions are not removed from currentSessionMap inside JTASessionContext. > Method JTASessionContext.CleanupSynch.afterCompletion() is called as expected but code "context.currentSessionMap.remove( txn );" does not remove session from Map because of key's hashcode has changed. This is due to fact that com.ibm.websphere.jtaextensions.ExtendedJTATransaction.hashCode is actually ID of underlaying transaction. But if it comes to the afterCompletion method in CleanupSynch the underlaying transaction is already closed. Closed transaction has ID 0 (default value) and it is different from ID under which the Hibernate session was previously inserted into Map. > Possible patch is in attachements. -- 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

17 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1821) Sorting based on an optionally associated column

by Diego Pires Plentz (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1821?page=c... ] Diego Pires Plentz commented on HHH-1821: ----------------------------------------- Please attach a runnable test case (java and mapping). But I think that is more a user problem (and not a bug). > Sorting based on an optionally associated column > ------------------------------------------------ > > Key: HHH-1821 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1821 > Project: Hibernate3 > Issue Type: Bug > Components: query-criteria > Affects Versions: 3.1 rc2 > Environment: JBoss 4.0.3SP1, Oracle 8.1 > Reporter: Mohammed Sadiq > Attachments: CmnCampusSchoolMstT.hbm.xml > > > Hi, > I have a table containing 3 assocations; out of which one is optional. When I give an order by clause for the optional assocation column (with an alias name in the Criteria) I get only those records for which this column has values, other records with null values are not listed. > As I went through the query generated by Hibernate I am surprised to see that the outer join symbol (+) was not there for this column, but was there when I try to order according to other associated columns. > I have attached my HBM file for your reference. > Any suggestion will be more helpful. > Thanks & Regards > Mohammed Sadiq -- 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

17 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Resolved: (HHH-1700) HAVING clause not supported in Criteria API

by Diego Pires Plentz (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1700?page=c... ] Diego Pires Plentz resolved HHH-1700. ------------------------------------- Assignee: Diego Pires Plentz Resolution: Duplicate > HAVING clause not supported in Criteria API > ------------------------------------------- > > Key: HHH-1700 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1700 > Project: Hibernate3 > Issue Type: New Feature > Components: query-criteria > Affects Versions: 3.1.3 > Environment: Hibernate 3.1.3, Oracle 10g (not DB specific) > Reporter: Manuel Dominguez Sarmiento > Assignee: Diego Pires Plentz > Priority: Minor > Attachments: CustomProjections.java > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > Currently the Criteria API does not support the HAVING clause. I have create a factory class which creates Projection instances using sqlGroupProjection. Probably not the best approach, but an idea which could be further developed. These factory methods could be included in the Projections factory class. > Usage example w/one property: > criteria.setProjection(CustomProjections.groupByHaving("id", Hibernate.LONG, "count(distinct id) >= 3")); > Also allows aliases: > criteria.setProjection(CustomProjections.groupByHaving("id", "idAlias", Hibernate.LONG, "count(distinct idAlias) >= 3")); > Usage example w/many properties: > String[] columns = new String[2]; > columns[0] = "id"; > columns[1] = "name"; > String[] aliases = new String[2]; > aliases[0] = "idAlias"; > aliases[1] = "nameAlias"; > Type[] types = new Type[2]; > types[0] = Hibernate.LONG; > types[1] = Hibernate.STRING; > criteria.setProjection(CustomProjections.groupByHaving(columns, aliases, types, "count(distinct id) >= 3 and name='george'")); -- 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

17 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1043) Added HAVING Support to Criteria

by Diego Pires Plentz (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1043?page=c... ] Diego Pires Plentz commented on HHH-1043: ----------------------------------------- HHH-1700 introduce another aproach. > Added HAVING Support to Criteria > -------------------------------- > > Key: HHH-1043 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1043 > Project: Hibernate3 > Issue Type: Patch > Components: query-criteria > Affects Versions: 3.1 rc 1 > Environment: 3.1 rc 1 > Reporter: Tony Voss > Priority: Minor > Attachments: criteria-having-improvement.patch, criteria-having-improvement.zip > > > I've added support for HAVING clauses to Criteria. Attached are my code changes. -- 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

17 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1575) Issue HHH-708 not properly fixed

by Diego Pires Plentz (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1575?page=c... ] Diego Pires Plentz commented on HHH-1575: ----------------------------------------- Please **attach** a runnable test case (java and mapping) :) > Issue HHH-708 not properly fixed > -------------------------------- > > 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

17 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2106) * criteria queries

by Toby (JIRA)

* criteria queries ------------------ Key: HHH-2106 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2106 Project: Hibernate3 Type: New Feature Components: query-criteria Reporter: Toby -localArea -wideArea - country Imagine you want to query local area that belong to a country, independet of the "wide area". But country is only references via a wide area and there is no direct link between local area and a country. You can not add wide area as a restriction as the problem ist, that you want all wide areas....and you only need them to get to the county..... Criteria c = session.createCriteria(LocalArea.class); c.add(Restrictions.eq("wideArea", *)); c.add(Restrictions.eq("country", country)); -- 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

17 years, 5 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2780) named parameter types

by jose (JIRA)

named parameter types --------------------- Key: HHH-2780 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2780 Project: Hibernate3 Issue Type: Patch Components: query-hql Affects Versions: 3.2.5, 3.2.4.sp1 Reporter: jose This query FAILS______________________ from Entity e where ((:status is null) or (e.status = :status)) This query WORK______________________ from Entity e where ((e.status = :status)) or (:status is null)) Fixed with_________________________________ Constructor of org.hibernate.hql.ast.ParameterTranslationsImpl ... else if ( NamedParameterSpecification.class.isAssignableFrom( spec.getClass() ) ) { NamedParameterSpecification namedSpec = ( NamedParameterSpecification ) spec; NamedParamTempHolder paramHolder = ( NamedParamTempHolder ) namedParameterMap.get( namedSpec.getName() ); if ( paramHolder == null ) { paramHolder = new NamedParamTempHolder(); paramHolder.name = namedSpec.getName(); paramHolder.type = namedSpec.getExpectedType(); namedParameterMap.put( namedSpec.getName(), paramHolder ); *** }else{ *** if (paramHolder.type == null){ *** paramHolder.type = namedSpec.getExpectedType(); *** } *** } paramHolder.positions.add( new Integer( i ) ); } else { // don't care about other param types here, just those explicitly user-defined... } -- 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

17 years, 5 months

2
1
0 / 0

[Hibernate-JIRA] Commented: (HHH-1396) Table.validateColumns fails on valid column

by Max Rydahl Andersen (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1396?page=c... ] Max Rydahl Andersen commented on HHH-1396: ------------------------------------------ yes - just telling what the general issue is ;) generally the validatecolumn method is waay to naive. > Table.validateColumns fails on valid column > ------------------------------------------- > > Key: HHH-1396 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1396 > Project: Hibernate3 > Issue Type: Bug > Components: metamodel > Affects Versions: 3.1.1 > Reporter: Christopher G. Stach II > Assignee: Diego Pires Plentz > Priority: Minor > > This may be an Annotations bug (3.1beta8), bug the exception happens in Core. > This column used to pass when I used this: > @Column(columnDefinition = "INT UNSIGNED NOT NULL DEFAULT 0", nullable = false) > I have since changed it to > @Column(columnDefinition = "INT UNSIGNED DEFAULT 0", nullable = false) > because "nullable = false" adds the "not null". > I am guessing that the nullable isn't being used in the validateColumns. I have not yet investigated, but the stack trace is below. > org.hibernate.tool.hbm2ddl.TableMetadata.<init> table found: xxx.yyy > org.hibernate.tool.hbm2ddl.TableMetadata.<init> columns: [foo_id, ipaddress, actiontype, timestamp, id] > com.caucho.server.webapp.Application.start org.hibernate.HibernateException: Wrong column type: ipAddress, expected: INT UNSIGNED DEFAULT 0 > at org.hibernate.mapping.Table.validateColumns(Table.java:219) > at org.hibernate.cfg.Configuration.validateSchema(Configuration.java:964) > at org.hibernate.tool.hbm2ddl.SchemaValidator.validate(SchemaValidator.java:116) > at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:296) > at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1164) > [...] -- 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

17 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1132) InformixDialect bug: in InformixDialect class

by Diego Pires Plentz (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1132?page=c... ] Diego Pires Plentz updated HHH-1132: ------------------------------------ Component/s: metamodel > InformixDialect bug: in InformixDialect class > ---------------------------------------------- > > Key: HHH-1132 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1132 > Project: Hibernate3 > Issue Type: Bug > Components: metamodel > Affects Versions: 3.1 rc2 > Environment: DB: InforMix 10.0 > Reporter: yu peng > > [registerColumnType(Types.DOUBLE, "double");] > in informix database no support double data type, > create table test ( col double) ----- syntax error; > suggest: double alter --> double precision or float -- 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

17 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues August 2007