August 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Closed: (HHH-1643) Sub-query as function parameter - either sub-query is missed from SQL or NullPointerException raised

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1643?page=c... ] Steve Ebersole closed HHH-1643. ------------------------------- Resolution: Fixed > Sub-query as function parameter - either sub-query is missed from SQL or NullPointerException raised > ---------------------------------------------------------------------------------------------------- > > Key: HHH-1643 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1643 > Project: Hibernate Core > Issue Type: Bug > Components: query-hql > Affects Versions: 3.1.2, 3.1.3 > Environment: Hibernate 3.1.2 MS SQL Server 2K > Reporter: Andy Shelton > Assignee: Steve Ebersole > Fix For: 3.6.0.Beta3, 3.5.5 > > Attachments: hql-sql.patch > > Time Spent: 35m > Remaining Estimate: 0h > > The HQL grammar HQL (hql.g) allows expressions and sub-queries as parameters to functions, however the SQL Tree Transform grammar (hql-sql.g) does not, it only allows expressions. This means if you pass a sub-query as a parameter to something like "cast" for example, you will get a NullPointerException. In other cases, typically the sub-query is missed out of the resulting SQL. This is easily remedied by changing the first line of the definition of functionCall within hql-sql.g from: > functionCall > : #(METHOD_CALL {inFunctionCall=true;} pathAsIdent ( #(EXPR_LIST (expr)* ) )? ) > to: > functionCall > : #(METHOD_CALL {inFunctionCall=true;} pathAsIdent ( #(EXPR_LIST (exprOrSubquery)* ) )? ) > This modification has been tested against all the existing UnitTests in Hibernate 3.1.2 and does not cause any problems. > I've included a patch for this. -- 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

13 years, 9 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-5469) HHH-3659 is only half done, due to HHH-4989 (i.e. no HQL performance log when running Java 5)

by Cédrik LIME (JIRA)

HHH-3659 is only half done, due to HHH-4989 (i.e. no HQL performance log when running Java 5) --------------------------------------------------------------------------------------------- Key: HHH-5469 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5469 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.0.Beta2, 3.6.0.Beta1, 3.5.4 Reporter: Cédrik LIME Priority: Trivial HHH-3659 introduced a well-deserved HQL execution time log, which is good. Unfortunately, HHH-4989 (Java 5 concurrent for statistics) didn't pick up those changes, so no execution time logs when running Java 5. To fix, add the same log statement to {{ConcurrentStatisticsImpl#queryExecuted(String hql, int rows, long time)}}: {code:java} log.info("HQL: {}, time: {}ms, rows: {}", new Object[]{hql, new Long(time), Long.valueOf(rows)}); {code} May I also suggest that we change this particular logger from whichever implementation class du jour to a {{org.hibernate.performance}} logger. -- 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

13 years, 9 months

2
3
0 / 0

[Hibernate-JIRA] Updated: (HHH-892) HQL parser does not resolve alias in ORDER BY clause

by Gail Badner (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-892?page=co... ] Gail Badner updated HHH-892: ---------------------------- Fix Version/s: (was: 3.6.x) (was: 3.5.x) 3.5.6 3.6.0.Beta4 > HQL parser does not resolve alias in ORDER BY clause > ----------------------------------------------------- > > Key: HHH-892 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-892 > Project: Hibernate Core > Issue Type: Bug > Components: query-hql > Affects Versions: 3.5.4, 3.6.0.Beta1 > Environment: Hibernate 3.0.5, MySQL, Tomcat > Reporter: Guido Laures > Assignee: Gail Badner > Fix For: 3.6.0.Beta4, 3.5.6 > > Attachments: HHH-892.patch, HibernateHavingAliasTest.java > > > When using an alias for an ORDER BY clause this is not always correctly resolved. Example: > SELECT SUM(A.x) AS mySum FROM MyClass AS A GROUP BY A.y ORDER BY mySum > does not work because "mySum" is not resolved in the ORDER BY clause which results in an exception telling that mySum is an unknown column. > Workaround (not to say "hack") is using: > SELECT SUM(A.x) AS mySum FROM MyClass AS A GROUP BY A.y ORDER BY col_0_0_ -- 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

13 years, 9 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-5464) Write a chapter about obtaining Hibernate

by Steve Ebersole (JIRA)

Write a chapter about obtaining Hibernate ----------------------------------------- Key: HHH-5464 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5464 Project: Hibernate Core Issue Type: Sub-task Reporter: Steve Ebersole Assignee: Steve Ebersole -- 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

13 years, 9 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5152) Update Configuration section to reflect Hibernate Annotations and Core documentation

by Emmanuel Bernard (JIRA)

Update Configuration section to reflect Hibernate Annotations and Core documentation ------------------------------------------------------------------------------------ Key: HHH-5152 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5152 Project: Hibernate Core Issue Type: Sub-task Reporter: Emmanuel Bernard -- 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

13 years, 9 months

3
7
0 / 0

[Hibernate-JIRA] Created: (HHH-5480) Upgrade jDocBook plugin to 2.3.1

by Steve Ebersole (JIRA)

Upgrade jDocBook plugin to 2.3.1 -------------------------------- Key: HHH-5480 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5480 Project: Hibernate Core Issue Type: Task Components: build Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.6.0.Beta3 -- 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

13 years, 9 months

1
2
0 / 0

[Hibernate-JIRA] Commented: (HHH-1869) The MultipleHiloPertablegenerator.class wraps at 2**31-1, but javadoc claims Long.

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1869?page=c... ] Steve Ebersole commented on HHH-1869: ------------------------------------- "... no longer relevant..." :) > The MultipleHiloPertablegenerator.class wraps at 2**31-1, but javadoc claims Long. > ---------------------------------------------------------------------------------- > > Key: HHH-1869 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1869 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.2.0 cr1 > Environment: All versions/all environments. > Reporter: Jan Helge Salvesen > Attachments: MultipleHiLoPerTableGenerator.zip > > > The returntype of org.hibernate.id.MultipleHiloPertablegenerator.doWorkInCurrentTransaction are Serializable, and the javadoc states that this class shall return a Long (line 26 in source-file). But the value to be returned are, in fact, treated as an Integer and thus limited to 31-bits positive numbers (as an Integer). See line 163 in class, for instance. This behaviour will cause problems for sequence numbers above Integer.MAX_VALUE (that is 2**31-1). When this limit is exceeded, the actual returned "Long" are a huge-negative integer and may potentinally cause damage. The reason for Priority:Major is the fact that user of this class may have an old-fashon databasescheme, and for this reason, this error may become a "ticking bomb" waiting to a sequence number to exceed 2**31-1. > The fixup are trivial. The internal representation of the number must be Long, and user shall be urged to upgrade to new release. > I have attached a fixed version of the MultipleHiloPertablegenerator.java where the generated sequencenumber are treated as a long. I have allso tested my modified version and verified that the sequence-generation part on a Oracle system works as expected, which is that the generated sequence actually can exceed 2**31-1. > (I have not tested the schema-generate-part, since this is not critical for user.) -- 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

13 years, 9 months

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-1869) The MultipleHiloPertablegenerator.class wraps at 2**31-1, but javadoc claims Long.

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1869?page=c... ] Steve Ebersole closed HHH-1869. ------------------------------- Resolution: Rejected This is no longer relative in current code and 3.2 branch is not maintained > The MultipleHiloPertablegenerator.class wraps at 2**31-1, but javadoc claims Long. > ---------------------------------------------------------------------------------- > > Key: HHH-1869 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1869 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.2.0 cr1 > Environment: All versions/all environments. > Reporter: Jan Helge Salvesen > Attachments: MultipleHiLoPerTableGenerator.zip > > > The returntype of org.hibernate.id.MultipleHiloPertablegenerator.doWorkInCurrentTransaction are Serializable, and the javadoc states that this class shall return a Long (line 26 in source-file). But the value to be returned are, in fact, treated as an Integer and thus limited to 31-bits positive numbers (as an Integer). See line 163 in class, for instance. This behaviour will cause problems for sequence numbers above Integer.MAX_VALUE (that is 2**31-1). When this limit is exceeded, the actual returned "Long" are a huge-negative integer and may potentinally cause damage. The reason for Priority:Major is the fact that user of this class may have an old-fashon databasescheme, and for this reason, this error may become a "ticking bomb" waiting to a sequence number to exceed 2**31-1. > The fixup are trivial. The internal representation of the number must be Long, and user shall be urged to upgrade to new release. > I have attached a fixed version of the MultipleHiloPertablegenerator.java where the generated sequencenumber are treated as a long. I have allso tested my modified version and verified that the sequence-generation part on a Oracle system works as expected, which is that the generated sequence actually can exceed 2**31-1. > (I have not tested the schema-generate-part, since this is not critical for user.) -- 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

13 years, 9 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-4441) SessionImpl serialization violates java serialization spec

by Paul Ferraro (JIRA)

SessionImpl serialization violates java serialization spec ---------------------------------------------------------- Key: HHH-4441 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4441 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.0.Beta-1, 3.3.2 Reporter: Paul Ferraro Attachments: patch.txt The private serialization methods of org.hibernate.impl.SessionImpl must call default[Read|Write]Object() on the object input/output stream before any custom de/serialization logic. According to the Java serialization spec: http://java.sun.com/javase/6/docs/platform/serialization/spec/output.html... "The class's writeObject method, if implemented, is responsible for saving the state of the class. Either ObjectOutputStream's defaultWriteObject or writeFields method must be called once (and only once) before writing any optional data that will be needed by the corresponding readObject method to restore the state of the object; even if no optional data is written, defaultWriteObject or writeFields must still be invoked once. If defaultWriteObject or writeFields is not invoked once prior to the writing of optional data (if any), then the behavior of instance deserialization is undefined in cases where the ObjectInputStream cannot resolve the class which defined the writeObject method in question." http://java.sun.com/javase/6/docs/platform/serialization/spec/input.html#... "The readObject method of the class, if implemented, is responsible for restoring the state of the class. The values of every field of the object whether transient or not, static or not are set to the default value for the fields type. Either ObjectInputStream's defaultReadObject or readFields method must be called once (and only once) before reading any optional data written by the corresponding writeObject method; even if no optional data is read, defaultReadObject or readFields must still be invoked once." One consequence of this spec violation is that you cannot use JBoss Marshalling to serialize a session. For details, see: https://jira.jboss.org/jira/browse/JBMAR-67 Patch attached. -- 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

13 years, 9 months

3
6
0 / 0

[Hibernate-JIRA] Commented: (HHH-1869) The MultipleHiloPertablegenerator.class wraps at 2**31-1, but javadoc claims Long.

by David Gleeson (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1869?page=c... ] David Gleeson commented on HHH-1869: ------------------------------------ This occurs in 3.2.7 {code} long hi; int hival = 21268146; // 21,268,146 int maxLo = 100; hi = hival * (maxLo+1); // hi wraps to -2,146,884,550 (int * int then extend) {code} > The MultipleHiloPertablegenerator.class wraps at 2**31-1, but javadoc claims Long. > ---------------------------------------------------------------------------------- > > Key: HHH-1869 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1869 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.2.0 cr1 > Environment: All versions/all environments. > Reporter: Jan Helge Salvesen > Attachments: MultipleHiLoPerTableGenerator.zip > > > The returntype of org.hibernate.id.MultipleHiloPertablegenerator.doWorkInCurrentTransaction are Serializable, and the javadoc states that this class shall return a Long (line 26 in source-file). But the value to be returned are, in fact, treated as an Integer and thus limited to 31-bits positive numbers (as an Integer). See line 163 in class, for instance. This behaviour will cause problems for sequence numbers above Integer.MAX_VALUE (that is 2**31-1). When this limit is exceeded, the actual returned "Long" are a huge-negative integer and may potentinally cause damage. The reason for Priority:Major is the fact that user of this class may have an old-fashon databasescheme, and for this reason, this error may become a "ticking bomb" waiting to a sequence number to exceed 2**31-1. > The fixup are trivial. The internal representation of the number must be Long, and user shall be urged to upgrade to new release. > I have attached a fixed version of the MultipleHiloPertablegenerator.java where the generated sequencenumber are treated as a long. I have allso tested my modified version and verified that the sequence-generation part on a Oracle system works as expected, which is that the generated sequence actually can exceed 2**31-1. > (I have not tested the schema-generate-part, since this is not critical for user.) -- 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

13 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues August 2010