August 2007 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2583) inconsistency in case sensitivity of dialect registered keywords

by Pete Cassin (JIRA)

inconsistency in case sensitivity of dialect registered keywords ---------------------------------------------------------------- Key: HHH-2583 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2583 Project: Hibernate3 Issue Type: Bug Components: documentation, query-hql Affects Versions: 3.2.3 Reporter: Pete Cassin Priority: Minor Right now, the Dialect.registerKeyword() method seems to add a given Keyword to the set as is, without taking the lower case. This would be fine if the intent was to allow case sensitive keywords, however it becomes problematic when these dialect specified keywords are used by the method Template.isFunctionOrKeyword() - the tokens passed to this method always have toLowerCase() called on them prior to being passed in. Thus, if I create a keyword "someKeyword" It will never be recognized as such because even if I included it in my hql with identical case, that method will always be checking the dialect's keyword set for "somekeyword". thus, HQL passed into Template.renderWhereStringTemplate will end up incorrectly qualifying the keyword with a table name. This isn't a serious bug by any means, but it may be good to at least note in documentation that user-specified keywords have to be all lowercase in order to function properly. -- 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
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2755) Small mistake in the tutorial

by Ales Nemochovsky (JIRA)

Small mistake in the tutorial ----------------------------- Key: HHH-2755 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2755 Project: Hibernate3 Issue Type: Deprecation Components: documentation Reporter: Ales Nemochovsky Priority: Minor In Hibernate tutorial (@ http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html) should be "jsdk.jar" replaced with "servlet.jar". That means it should be also replaced in the file doc/tutorial/build.xml (on line 42). There are two reasons for that. Sun offers 2 implementations of JSDK: 1) JSDK 2.0 which contains jsdk.jar. But jsdk.jar doesn't implement constructor ServletException(Throwable), which is needed in file doc/tutorial/src/events/EventManagerServlet.java (on line 58). 2) JSDK 2.1 which contains !servlet.jar! is OK. -- 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
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2542) NullPointerException in TypeFactory.replaceAssociations for ComponentType

by Reto Urfer (JIRA)

NullPointerException in TypeFactory.replaceAssociations for ComponentType ------------------------------------------------------------------------- Key: HHH-2542 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2542 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.3 Reporter: Reto Urfer The following code block will throw a NullPointerException when targetComponentValues should be determines and target[i] contains a NULL value. else if ( types[i].isComponentType() ) { // need to extract the component values and check for subtype replacements... AbstractComponentType componentType = ( AbstractComponentType ) types[i]; Type[] subtypes = componentType.getSubtypes(); Object[] origComponentValues = original[i] == null ? new Object[subtypes.length] : componentType.getPropertyValues( original[i], session ); Object[] targetComponentValues = componentType.getPropertyValues( target[i], session ); replaceAssociations( origComponentValues, targetComponentValues, subtypes, session, null, copyCache, foreignKeyDirection ); This problem can be fixed the same way as it is prevented when origComponentValues are determined (see following line) Object[] targetComponentValues = target[i] == null ? new Object[subtypes.length] : componentType.getPropertyValues( target[i], session ); copied[i] = target[i]; } The problem did not exist in Version 3.2.2 -- 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

3
8
0 / 0

[Hibernate-JIRA] Created: (HHH-2779) Column value incorrectly enclosed in square brackets in SQL generated by Hibernate when using Restrictions.ne with ignoreCase()

by Vladimir Strugatsky (JIRA)

Column value incorrectly enclosed in square brackets in SQL generated by Hibernate when using Restrictions.ne with ignoreCase() ------------------------------------------------------------------------------------------------------------------------------- Key: HHH-2779 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2779 Project: Hibernate3 Issue Type: Bug Components: query-criteria Affects Versions: 3.1.3 Environment: Both MySQL and Oracle, Java 5.0 Reporter: Vladimir Strugatsky These are the generated FROM and WHERE clauses: from IMPACTS this_ left outer join IMPACT_DEGREE_TYPES alias_1x1_ on this_.ID_IMPACT_DEGREE_TYPES=alias_1x1_.ID_IMPACT_DEGREE_TYPES where lower(alias_1x1_.IMPACT_DEGREE_TYPE)<>? And here is the value of the IMPACT_DEGREE_TYPE as generated by Hibernate: [2007-08-13 19:13:31,039]: [DEBUG] org.hibernate.type.StringType - binding '[0 - no impact]' to parameter: 1 The value that we pass to Restrictions.ne() is '0 - No Impact' . Hibernate correctly converts the value to the lower case, because we use ignoreCase(). But it also encloses the value in square brackets, which, of course, breaks the query. -- 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

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2786) SQL Server dialect fails to set com.microsoft.sqlserver.jdbc.SQLServerResultSet.TYPE_SS_SERVER_CURSOR_FORWARD_ONLY when needed

by Benson Margulies (JIRA)

SQL Server dialect fails to set com.microsoft.sqlserver.jdbc.SQLServerResultSet.TYPE_SS_SERVER_CURSOR_FORWARD_ONLY when needed ------------------------------------------------------------------------------------------------------------------------------ Key: HHH-2786 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2786 Project: Hibernate3 Issue Type: Bug Components: query-sql Affects Versions: 3.2.0.ga Environment: Windows. Microsoft SQL Server JDBC driver version 1.1. Reporter: Benson Margulies If I leave the selectMethod=cursor out of my JDBC URL, and use a FORWARD_ONLY to the scroll() method, I still run out of memory trying to retrieve the entire contents of the database from the server. As I read the MS dfoc, the com.microsoft.sqlserver.jdbc.SQLServerResultSet.TYPE_SS_SERVER_CURSOR_FORWARD_ONLY option should get used by the dialect to have the desired effect without the connection option. -- 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] Closed: (HHH-1942) Interfaces PreInsertEventListener and PreUpdateEventListener are badly javadoc-documented

by George Gastaldi (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1942?page=c... ] George Gastaldi closed HHH-1942. -------------------------------- Couldn't find the documentation on the classes. > Interfaces PreInsertEventListener and PreUpdateEventListener are badly javadoc-documented > ----------------------------------------------------------------------------------------- > > Key: HHH-1942 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1942 > Project: Hibernate3 > Issue Type: Task > Components: documentation > Affects Versions: 3.1.3, 3.2.0 cr1, 3.2.0.cr2, 3.2.0.cr3 > Reporter: George Gastaldi > Assignee: Diego Pires Plentz > Priority: Trivial > > Provide proper documentation for org.hibernate.event.PreUpdateEventListener and org.hibernate.event.PreInsertEventListener. > Like: > 1) What does the return method (boolean) of their methods mean ? > 2) Who calls it and when ? > 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] Created: (HHH-2785) CollectionMetadata should expose isInverse() method

by Manuel Dominguez Sarmiento (JIRA)

CollectionMetadata should expose isInverse() method --------------------------------------------------- Key: HHH-2785 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2785 Project: Hibernate3 Issue Type: Improvement Affects Versions: 3.2.5 Reporter: Manuel Dominguez Sarmiento Priority: Minor We've come across the need to determine whether a collection is inverse or not. CollectionMetadata should expose the method directly. Indirectly, we can do this: if (collectionMetadata instanceof CollectionPersister) { boolean inverse = ((CollectionPersister) collectionMetadata).isInverse(); ... } This works because AbstractCollectionPersister implements both CollectionMetadata and CollectionPersister, however it is not very OO. Implementing this would be simply a matter of adding the method declaration to CollectionMetadata, since the only existing implementation already has that method. -- 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-1942) Interfaces PreInsertEventListener and PreUpdateEventListener are badly javadoc-documented

by Diego Pires Plentz (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1942?page=c... ] Diego Pires Plentz resolved HHH-1942. ------------------------------------- Assignee: Diego Pires Plentz Resolution: Fixed Already "javadoc-documented". > Interfaces PreInsertEventListener and PreUpdateEventListener are badly javadoc-documented > ----------------------------------------------------------------------------------------- > > Key: HHH-1942 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1942 > Project: Hibernate3 > Issue Type: Task > Components: documentation > Affects Versions: 3.1.3, 3.2.0 cr1, 3.2.0.cr2, 3.2.0.cr3 > Reporter: George Gastaldi > Assignee: Diego Pires Plentz > Priority: Trivial > > Provide proper documentation for org.hibernate.event.PreUpdateEventListener and org.hibernate.event.PreInsertEventListener. > Like: > 1) What does the return method (boolean) of their methods mean ? > 2) Who calls it and when ? > 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] Created: (HHH-2369) Documentation doesn't state what hibernate returns for empty/null collections

by James Roper (JIRA)

Documentation doesn't state what hibernate returns for empty/null collections ----------------------------------------------------------------------------- Key: HHH-2369 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2369 Project: Hibernate3 Type: Improvement Components: documentation Versions: 3.2.1 Reporter: James Roper Priority: Trivial Reading the hibernate documentation, section 6.1: "Hibernate does not distinguish between a null collection reference and an empty collection" This is all very well, but what does hibernate return when loading a null/empty collection? According to the EJB3 specification, section 2.1.7: "If there are no associated entities for a multi-valued relationship of an entity fetched from the database, the persistence provider is responsible for returning an empty collection as the value of the relationship." If this is the behavior that hibernate implements, then this should be explicitly stated in the hibernate documentation, so that developers know whether they need to do null checks or not after loading an object from the database. -- 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
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2468) Is setParameter 0- or 1-based?

by Rafael Borges (JIRA)

Is setParameter 0- or 1-based? ------------------------------ Key: HHH-2468 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2468 Project: Hibernate3 Type: Bug Versions: 3.2.2 Environment: Hibernate 3.2.2.GA, RDBMS: H2, version: 1.0 (2007-01-30), JDK 6.0, Windows XP Pro Reporter: Rafael Borges Priority: Trivial The following query throws a wrong message in the Exception == Query == query = session.createQuery("select t from Test t where t.id = ?"); query.setParameter(1, 1); == Message == Exception in thread "main" java.lang.IndexOutOfBoundsException: Remember that ordinal parameters are 1-based! at org.hibernate.engine.query.ParameterMetadata.getOrdinalParameterDescriptor(ParameterMetadata.java:55) at org.hibernate.engine.query.ParameterMetadata.getOrdinalParameterExpectedType(ParameterMetadata.java:61) at org.hibernate.impl.AbstractQueryImpl.determineType(AbstractQueryImpl.java:397) at org.hibernate.impl.AbstractQueryImpl.setParameter(AbstractQueryImpl.java:369) at Test.main(Test.java:25) The Javadoc says it is 0-based, and that works perfectly when used accordingly. So I think it is just a comestic fix. -- 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
3
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