April 2007 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2164) Minor bug in section "20.1.1. Customizing the schema"

by Andres Gonzalez (JIRA)

Minor bug in section "20.1.1. Customizing the schema" ----------------------------------------------------- Key: HHH-2164 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2164 Project: Hibernate3 Type: Bug Components: documentation Versions: 3.2.0.ga Reporter: Andres Gonzalez Where it says: ******************************************************************************************************************************* A unique-key attribute may be used to group columns in a single unique key constraint. Currently, the specified value of the unique-key attribute is not used to name the constraint in the generated DDL, only to group the columns in the mapping file. <many-to-one name="org" column="orgId" unique-key="OrgEmployeeId"/> <property name="employeeId" unique-key="OrgEmployee"/> ******************************************************************************************************************************* i think the unique-key attributes should jave both the same value ("OrgEmployee", for example) -- 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, 8 months

2
2
0 / 0

[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

18 years, 8 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

18 years, 8 months

3
8
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

18 years, 8 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

18 years, 8 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2519) Schema dropping not documented with hibernate.hbm2ddl.auto=create

by Ville Skyttä (JIRA)

Schema dropping not documented with hibernate.hbm2ddl.auto=create ----------------------------------------------------------------- Key: HHH-2519 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2519 Project: Hibernate3 Issue Type: Patch Components: documentation Environment: svn trunk Reporter: Ville Skyttä Attachments: create-drops.patch Dropping the schema is not documented with hibernate.hbm2ddl.auto=create, fix 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

18 years, 8 months

2
1
0 / 0

[Hibernate-JIRA] Created: (ANN-530) introduce fetch_size for Hibernate Search scrollable resultsets.

by Emmanuel Bernard (JIRA)

introduce fetch_size for Hibernate Search scrollable resultsets. ---------------------------------------------------------------- Key: ANN-530 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-530 Project: Hibernate Annotations Type: New Feature Components: search 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

18 years, 8 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HHH-2566) Remove FlushMode.NEVER

by Diego Pires Plentz (JIRA)

Remove FlushMode.NEVER ---------------------- Key: HHH-2566 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2566 Project: Hibernate3 Issue Type: Task Components: core Reporter: Diego Pires Plentz -- 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, 8 months

3
16
0 / 0

[Hibernate-JIRA] Created: (HBX-915) CLONE -Hibernate ant task does not work in a multi-project Maven 2 build if other mojos use javax.xml.transform

by Brill Pappin (JIRA)

CLONE -Hibernate ant task does not work in a multi-project Maven 2 build if other mojos use javax.xml.transform --------------------------------------------------------------------------------------------------------------- Key: HBX-915 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-915 Project: Hibernate Tools Type: Bug Components: ant Versions: 3.1beta4 Environment: Hibernate 3.1, database is Oracle (but not relevant to this) Reporter: Brill Pappin Fix For: 3.2beta7 I have a reasonably complex maven 2 build with multiple projects. More than one of the projects uses the hbm2java task and at least one of the projects uses the Codehaus xslt-maven-plugin. When running the project that uses both hbm2java and XSLT, it works fine. But running the master build throws the following error. org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant tasks at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) [snip] Caused by: java.lang.IllegalStateException: 3.1.0.beta4 found when setting version at org.hibernate.tool.hbm2x.TemplateHelper.putInContext(TemplateHelper.java:223) [snip] I can't really explain where this error is coming from. I looked at the source for putInContext and it is using the Plexus options class and failing because the value of "version" is already in the options. I assumed from this it was a problem with the xstl-maven-plugin from Codehaus also using some Plexus libraries, but I refactored the mojo so it was ONLY using javax.xml.transform and the problem remained. I then changed my slimmed down mojo to force use of Saxon instead of the default JAXP implementation (Xalan?). .. and it worked fine! So this is definitely a problem with the instantiation of the default XSLT functionality in JDK1.4, although how that can possibly affect the build in this way is beyond me. You might consider this a Maven bug but it's very strange that it doesn't happen for any old mojo combination. I also think it is probably much easier to fix in Hibernate tools than in Maven. I'd suggest a couple of possible fixes/improvements: - Make "version" key more specific, eg. hibernate.tools.version to avoid possible clash with other Plexus clients in the same JVM - Don't throw an exception on any existing value being set as it is now but compare the value in the options to the new value and only throw an exception if they differ I can't think of a way to track down the underlying cause of this issue. It's a very odd one. Attached is a simple three project build to reproduce the problem. Just run 'mvn clean package' on the parent project to reproduce. -- 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, 8 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2342) support <load-collection> for stored procedures (see 3.2 documentation section 16.2.2)

by Rick Bradshaw (JIRA)

support <load-collection> for stored procedures (see 3.2 documentation section 16.2.2) -------------------------------------------------------------------------------------- Key: HHH-2342 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2342 Project: Hibernate3 Type: New Feature Components: core Environment: Any new hibernate version/update - Oracle is my personal DBMS preference Reporter: Rick Bradshaw In the 3.2 documentation 16.2.2 "Using Stored Procedures for Querying" it specifies that "<load-collection>" is not supported. The ability to load collections from stored procedures is a powerful idea. I have done it manually within my own Java implementation and it is a big time / headache saver. Many of the DB models I work with (and don't have control of) are full of inconsistencies that can be re-modeled and disguised within a stored procedure that returns sys_refcursor. Adding the <load-collection> feature will make it really easy/fast to map into hibernate the result sets of stored procedures. -- 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, 8 months

2
1
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 April 2007