July 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (ANN-668) Method in entity with return type of ArrayList<Object[]> causes failure to build session factory

by Clint Popetz (JIRA)

Method in entity with return type of ArrayList<Object[]> causes failure to build session factory ------------------------------------------------------------------------------------------------ Key: ANN-668 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-668 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.3.0.ga Environment: Hibernate 3.2.X, no database needed (happens during factory build before connecting to db) Reporter: Clint Popetz Attachments: propertyTypeExtractorBug.tar.gz The following source: @javax.persistence.Entity public class TestEntity { @javax.persistence.Id public int Id; public java.util.ArrayList<Object[]> badMethod() { return null; } public static void main(String args[]) { new org.hibernate.cfg.AnnotationConfiguration().addAnnotatedClass(TestEntity .class).configure().buildSessionFactory(); } } will cause: java.lang.IllegalArgumentException: No PropertyTypeExtractor available for type void at org.hibernate.annotations.common.reflection.java.JavaReflectionManager.toXType(JavaReflectionManager.java:164)^M at org.hibernate.annotations.common.reflection.java.JavaXMethod.create(JavaXMethod.java:18) at org.hibernate.annotations.common.reflection.java.JavaReflectionManager.getXMethod(JavaReflectionManager.java:128) at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredMethods(JavaXClass.java:114) at org.hibernate.validator.ClassValidator.initValidator(ClassValidator.java:214) at org.hibernate.validator.ClassValidator.<init>(ClassValidator.java:133) at org.hibernate.validator.event.ValidateEventListener.initialize(ValidateEventListener.java:91) at org.hibernate.event.EventListeners.initializeListeners(EventListeners.java:356) at org.hibernate.cfg.Configuration.getInitializedEventListeners(Configuration.java:1304) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1294) Changing the return type to List<Object[]> avoids the bug. Attached is a tgz of an ant-buildable project; typing "ant run" will illustrate the bug. -- 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

15 years, 5 months

6
7
0 / 0

[Hibernate-JIRA] Created: (HHH-3873) DB2Dialect.getLimitString raise DB2 error message when called with limit=0

by Julien Kronegg (JIRA)

DB2Dialect.getLimitString raise DB2 error message when called with limit=0 -------------------------------------------------------------------------- Key: HHH-3873 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3873 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Environment: DB2, http://viewvc.jboss.org/cgi-bin/viewvc.cgi/hibernate/core/branches/Branch... http://viewvc.jboss.org/cgi-bin/viewvc.cgi/hibernate/core/branches/Branch... Reporter: Julien Kronegg Priority: Minor Executing a query called with setMaxResults(n) makes the underlying Hibernate code to call DB2Dialect.getLimitString. While this is working fine in general case, the following database error is raised when setting the maximum number of results to zero: SqlException: NUMBER 0 DIRECTLY SPECIFIED IN AN SQL STATEMENT IS OUTSIDE THE RANGE OF ALLOWABLE VALUES IN THIS CONTEXT (1, 2147483647) This is due to the getLimitString method in classes DB2400Dialect and DB2390Dialect : public String getLimitString(String sql, int offset, int limit) { return new StringBuffer(sql.length() + 40) .append(sql) .append(" fetch first ") .append(limit) .append(" rows only ") .toString(); } When the limit parameter is set to zero, the fetch limit is appended, which explains why the error message occur. Solution: ------------ When the limit is 0, there should be no "fetch first" instruction appended (as 0 is the general convention for "no limit"). The code would be: public String getLimitString(String sql, int offset, int limit) { + if (limit==0) return sql; return new StringBuffer(sql.length() + 40) .append(sql) .append(" fetch first ") .append(limit) .append(" rows only ") .toString(); } Workaround: ------------------ In order to avoid the error message, getLimitString(n) or setMaxResults(n) should be called with the 'newN' argument: int newN = (n==0?Integer.MAX_VALUE:n); Note: since the workaround is quite easy, I set the priority to "Minor" -- 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

15 years, 5 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3144) Final methods preclude some useful Hibernate extensions

by Ali Ibrahim (JIRA)

Final methods preclude some useful Hibernate extensions ------------------------------------------------------- Key: HHH-3144 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3144 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.2.6 Reporter: Ali Ibrahim Priority: Minor The following methods are final: AbstractPersistentCollection#read, AbstractPersistentCollection#write, AbstractLazyInitializer#initialize. It can be useful to override these methods. Fix is to make them protected. -- 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

15 years, 5 months

2
2
0 / 0

[Hibernate-JIRA] Created: (ANN-470) enrich UniqueConstraint with property name

by Johnny D. (JIRA)

enrich UniqueConstraint with property name ------------------------------------------ Key: ANN-470 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-470 Project: Hibernate Annotations Type: Improvement Reporter: Johnny D. To be able in annotation to give uniqueConstraint exact database name, there is need to add field java.lang.String name(); to annotation class UniqueConstraint in similar way like in index is. -- 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

15 years, 5 months

5
10
0 / 0

[Hibernate-JIRA] Created: (HHH-4042) StatelessSession does not flush when using jdbc batch_size > 1

by Gael Beaudoin (JIRA)

StatelessSession does not flush when using jdbc batch_size > 1 -------------------------------------------------------------- Key: HHH-4042 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4042 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Environment: JBoss 4.2.3, Linux, java 1.6, hibernate 3.3.1, entityManager 3.4.0, jboss seam 2.1.2, postgresql 8.3 Reporter: Gael Beaudoin I'm using a StetelessSession to insert millions of rows : it works great and without using much memory. But I've just seen that with a jdbc batch size of 50 for example (<property name="hibernate.jdbc.batch_size" value="0"/> in my persistence.xml) the last round of inserts aren't flushed to the database. For example, with 70 insert, only the first 50 are sent to the database. I've searched a lot about this issues and on this thread (https://forum.hibernate.org/viewtopic.php?f=1&t=987882&start=0), the only solution found is to set the batch_size to 1, which is really a shame. I've tried to flush the session, close the jdbc connection, etc etc ... no luck. I'd be fine with a way to set the batch_size to 1 only for this method, pro grammatically, but I've not found any way to do that. If you don't pay attention, it's a easy way to lose data. -- 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

15 years, 5 months

5
7
0 / 0

[Hibernate-JIRA] Created: (HHH-2319) StatelessInterceptor

by Max Rydahl Andersen (JIRA)

StatelessInterceptor -------------------- Key: HHH-2319 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2319 Project: Hibernate3 Type: New Feature Components: core Versions: 3.2.1 Reporter: Max Rydahl Andersen It would make sense to have an Interceptor for StatelessSession to solve the following usecases: Log/adjust SQL: onPrepareStatement Proper entityname handling: instantiate/getEntity Maybe also tx interaction: afterTransationBegin/beforeTransactionCompletion/afterTransactionCompletion Technically it could be solved by just allowing to pass in a normal interceptor to a StatelessSession and just document that the state oriented callbacks will not be called. Alternatively we can create a StatelessInterceptor that only implement the releavant methods and wrap that instance into an internal Interceptor. -- 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

15 years, 5 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2007) Hibernate doesn't support optional one-to-one associations

by Andrei Iltchenko (JIRA)

Hibernate doesn't support optional one-to-one associations ---------------------------------------------------------- Key: HHH-2007 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2007 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.cr2 Reporter: Andrei Iltchenko Hibernate doesn't properly support optional one-to-one associations, e.g. Person (0..1) -- (0..1) Passport. The Hibernate books and reference all talk of two ways of mapping one-to-one associations: 1. using a many-to-one fk association with a unique constraint on the fk; 2. using a pk association. the trouble with both of them is that they enforce the mandatory property of an association end, which sometimes is not desirable. The first way enforces the mandatory property with the uniqueness constraint on the fk, the other by using the fact that one table's pk is its fk. I tried to see if I could adapt the 1st way of representing one-to-ones to support optional association ends. What I did was simply remove the unique and not null constrains from DDL generated (without removing it it would be impossible to have a Person record that doesn't reference a Passport record): from CREATE TABLE Person ( PassUniqueId VARCHAR (32) NOT NULL, version INTEGER NOT NULL, uniqueId VARCHAR (32) NOT NULL, name VARCHAR (40) NULL, PRIMARY KEY (uniqueId), UNIQUE(PassUniqueId), FOREIGN KEY (PassUniqueId) REFERENCES Passport (uniqueId) ); to CREATE TABLE Person ( PassUniqueId VARCHAR (32) NULL, version INTEGER NOT NULL, uniqueId VARCHAR (32) NOT NULL, name VARCHAR (40) NULL, PRIMARY KEY (uniqueId), FOREIGN KEY (PassUniqueId) REFERENCES Passport (uniqueId) ); but leave the uniqueness attribute in the mapping file: <many-to-one name="pass" class="application.business.logic.Passport" cascade="save-update,merge" unique="true" > <column name="PassUniqueId"/> </many-to-one> The resulting solution worked fine and I was able to create instances of Person not linked to a Passport. However Hibernate didn't succed in keeping the association from degrading into a many-to-one. It enabled me to create two Persons linked with the same Passport: PASSUNIQUEID | VIRSION | UNIQUEID | Name ================================================ 0d8b3919fffff | 1 | 0d5fb1dcfff | John 0d8b3919fffff | 0 | 10fd07bdfff | Sam A subsequent attempt at retrieving such Persons with Hibernate failed: org.hibernate.HibernateException: More than one row with the given identifier was found: 0d8b3919ffffffd60151e135b6da0164, for class: application.business.logic.Passport. Hibernate should be able to impose the single end property of such associations without relying on the underlying RDBMS engine and never allow them to degrade to many-to-ones. -- 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

15 years, 5 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HV-24) Improve the default message of InvalidStateException

by Mike Quilleash (JIRA)

Improve the default message of InvalidStateException ---------------------------------------------------- Key: HV-24 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-24 Project: Hibernate Validator Issue Type: Improvement Components: engine Affects Versions: 3.0.0.ga Environment: Any Reporter: Mike Quilleash Doing a printStackTrace on InvalidStateException does not give the actual invalid values anywhere. Would greatly improving debugging speed if this was included by default as often this indicates a programming error. Currently I have to run the code again and debug the right place to find out what the InvalidValues are. -- 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

15 years, 5 months

7
14
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-371) Refactor DocumentBuilder and introduce abstract base class

by Hardy Ferentschik (JIRA)

Refactor DocumentBuilder and introduce abstract base class ---------------------------------------------------------- Key: HSEARCH-371 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-371 Project: Hibernate Search Issue Type: Task Components: engine Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 3.2.0 Further improvement of the document builder. Introducing a common base class and moving some methods into there and taking care of some not so nice method overriding between the two existing DocumentBuilders will further improve the design of these classes. -- 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

15 years, 6 months

3
7
0 / 0

[Hibernate-JIRA] Created: (HHH-2835) Setting org.hibernate.type logging to debug produces no logging

by Jeremy Grodberg (JIRA)

Setting org.hibernate.type logging to debug produces no logging --------------------------------------------------------------- Key: HHH-2835 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2835 Project: Hibernate3 Issue Type: Bug Components: core, documentation Affects Versions: 3.2.5, 3.2.4 Environment: Hibernate 3.2.4.ga and Hibernate 3.2.5.ga with MySQL5Dialect (configured with Hibernate Annotations 3.3.0.ga and Spring 2.0.6) Reporter: Jeremy Grodberg Priority: Minor According to the online documentation (labeled as version 3.2.2 at this moment), Table 3.9 "Hibernate Log Categories", as viewed here today: http://www.hibernate.org/hib_docs/v3/reference/en/html/session-configurat... Setting the log4j category "org.hibernate.type" to debug should "Log all JDBC parameters". However, it produces no output at all. When I go on to set "org.hibernate" to debug, I get output like this: DEBUG: org.hibernate.jdbc.AbstractBatcher - about to open PreparedStatement (open PreparedStatements: 0, globally: 0) DEBUG: org.hibernate.SQL - select count(*) from album where genreID=? DEBUG: org.hibernate.loader.Loader - bindNamedParameters() 126 -> genreId [1] DEBUG: org.hibernate.jdbc.AbstractBatcher - about to open ResultSet (open ResultSets: 0, globally: 0) DEBUG: org.hibernate.loader.Loader - result row: DEBUG: org.hibernate.jdbc.AbstractBatcher - about to close ResultSet (open ResultSets: 1, globally: 1) DEBUG: org.hibernate.jdbc.AbstractBatcher - about to close PreparedStatement (open PreparedStatements: 1, globally: 1) Note that the JDBC parameters are logged under org.hibernate.loader but nothing appears under org.hibernate.type. FYI, genreId is, in this case, a Long. Perhaps this is expected/desired when using annotations? If so, then please update the documentation. If not, please restore the logging. -- 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

15 years, 6 months

10
10
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 July 2009