February 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-7040) Define source of "id generators"

by Steve Ebersole (JIRA)

Define source of "id generators" -------------------------------- Key: HHH-7040 URL: https://hibernate.onjira.com/browse/HHH-7040 Project: Hibernate ORM Issue Type: Task Components: core, metamodel Reporter: Steve Ebersole Fix For: 5.0.0 This is annotation specific, but create the notion of source for "global" identifier generator definitions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HHH-4808) SessionImpl.initializeCollection() does not release JDBC connection (if outside of a transaction)

by Martin Renner (JIRA)

SessionImpl.initializeCollection() does not release JDBC connection (if outside of a transaction) ------------------------------------------------------------------------------------------------- Key: HHH-4808 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4808 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.2, 3.2.7 Reporter: Martin Renner Priority: Critical With {{ConnectionReleaseMode.AFTER_TRANSACTION}} (the default), Hibernate does not release the JDBC connection when resolving a lazily loaded collection, if this happens *outside* of an active transaction. First, I will describe, what happens if Hibernate executes a query outside of a transaction. Then I will describe how lazy collection loading behaves differently. When the method {{list}} of a query ({{QueryImpl.java}}) is getting called, Hibernate delegates to {{SessionImpl.list()}}. After having loaded the list, {{SessionImpl.list()}} calls {{SessionImpl.afterOperation()}}, which calls {{jdbcContext.afterNontransactionalQuery()}} (as there is no active transaction). This leads to {{ConnectionManager.afterTransaction()}} which releases the JDBC connection. This is exactly what I expect to happen. Now to the lazily loaded collection: {{Hibernate.initialize(collection)}} and {{person.getPets().size()}} both end up in {{SessionImpl.initializeCollection()}}. This call gets dispatched down to {{Loader.doQueryAndInitializeNonLazyCollections()}} and {{Loader.doQuery()}}. The important fact is, that {{ConnectionManager.afterTransaction()}} never gets called (like in the query-example above). The result is, that the JDBC connection is not released. IMHO resolving of a lazily loaded collection should behave like executing a query. {{SessionImpl.initializeCollection()}} should call {{SessionImpl.afterOperation()}} in the same way as {{SessionImpl.list()}} is doing this. I will attach a small demo application which shows the difference (concerning {{ConnectionManager}}) between queries and collections. -- 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

12 years, 9 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HV-554) Regular Expression for @Email

by William Hardwick (JIRA)

Regular Expression for @Email ------------------------------ Key: HV-554 URL: https://hibernate.onjira.com/browse/HV-554 Project: Hibernate Validator Issue Type: Improvement Components: validators Affects Versions: 4.2.0.Final Reporter: William Hardwick Priority: Minor It would be nice if @Email allowed for a regular expression like @URL does. For example, we wanted to restrict emails to external addresses only (i.e. ending in .com, .net, etc.), but the @Email validation allows internal addresses as well, for example bob@mycompany instead of bob(a)mycompany.com. We had to write our own custom validation to handle this. @Email(regexp="myRegexp") -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

3
5
0 / 0

[Hibernate-JIRA] Created: (HHH-5950) Make @UniqueConstraint inheritable

by Manuel Bernhardt (JIRA)

Make @UniqueConstraint inheritable ---------------------------------- Key: HHH-5950 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5950 Project: Hibernate Core Issue Type: New Feature Components: annotations Affects Versions: 3.6.1 Reporter: Manuel Bernhardt It would be really nice to be able to define a @UniquenessConstraint in a @MappedSuperclass so that all subclasses carry this constraint. Right now, the following constraint is ignored: @MappedSuperclass @Table(uniqueConstraints = {@UniqueConstraint(name="inheritedConstraint", columnNames = {"matter", "value"})}) public class Space { ... } -- 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

12 years, 9 months

3
5
0 / 0

[Hibernate-JIRA] Created: (HHH-6572) IdentifierGeneratorHelper.getGeneratedIdentity() assumes that id column will always be at index 1

by Richard Ballard (JIRA)

IdentifierGeneratorHelper.getGeneratedIdentity() assumes that id column will always be at index 1 ------------------------------------------------------------------------------------------------- Key: HHH-6572 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6572 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.3 Environment: Using Hibernate core 3.6.3 against Postgres driver 9.0-801.jdbc4 (underlying postgres version 9.0) Reporter: Richard Ballard If the database columns are created such that the serial id is *not* the first one, then the EntityManager.persist(Object) method sets the wrong value on the entity's @Id field (it sets it to the value of the first db column). For example: Create the table: CREATE TABLE info.rmbtest_course2 ( fee integer, id bigserial NOT NULL, starttime timestamp without time zone, title character varying(100) NOT NULL, CONSTRAINT rmbtest_course2_pkey PRIMARY KEY (id) ) *Note that the id column is the second column*. Create the entity: package testhibernate.course; import org.hibernate.annotations.GenericGenerator; import org.hibernate.annotations.Type; import org.joda.time.DateTime; import javax.persistence.Column; import javax.persistence.Entity; import javax.persistence.GeneratedValue; import javax.persistence.GenerationType; import javax.persistence.Id; import javax.persistence.IdClass; import javax.persistence.NamedQueries; import javax.persistence.NamedQuery; import javax.persistence.Table; @Entity(name = "course") @Table(name = "rmbTest_course2", schema = "info") @NamedQueries(@NamedQuery(name = "Course.findByTest", query = "from course")) public class Course { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Column(name = "ID") private final Long id; @Column(name = "TITLE", length = 100, nullable = false) private final String title; @Column(name = "FEE") private final int fee; @Column(name = "startTime") @Type(type="org.jadira.usertype.dateandtime.joda.PersistentDateTime") private final DateTime startTime; public Course(final String title, final int fee, final DateTime startTime) { this.id = null; this.title = title; this.fee = fee; this.startTime = startTime; } /** * Required by JPA */ public Course() { id = null; title = null; fee = 0; startTime = null; } public CourseKey getKey() { return new CourseKey(id); } public String getTitle() { return title; } public int getFee() { return fee; } public DateTime getStartTime() { return startTime; } @Override public String toString() { return "Course{" + "id=" + id + ", title='" + title + '\'' + ", fee=" + fee + ", startTime=" + startTime + '}'; } } Run this code: Course course = new Course("Core Spring", 1000, new DateTime()); course = myRepository.save(course); System.out.println("key = " + course.getKey()); In this case the returned course.getKey() should've been the auto allocated serial id, but it is 1000, i.e. the first column in the table. The problem is that IdentifierGeneratorHelper.get(ResultSet rs, Type type) assumes that the id column is always the first column. As a workaround I have set my entities @Id annotations to: ... public class Course { @Id @GeneratedValue(generator = "myGenerator") @GenericGenerator(name = "myGenerator", strategy = "testhibernate.MyGenerator") @Column(name = "ID") private final Long id; ... and had the following Generator code: package testhibernate; import org.hibernate.HibernateException; import org.hibernate.dialect.Dialect; import org.hibernate.id.IdentifierGenerationException; import org.hibernate.id.IdentifierGeneratorHelper; import org.hibernate.id.IdentityGenerator; import org.hibernate.id.PostInsertIdentityPersister; import org.hibernate.id.ResultSetIdentifierConsumer; import org.hibernate.id.insert.InsertGeneratedIdentifierDelegate; import org.hibernate.persister.entity.SingleTableEntityPersister; import org.hibernate.type.CustomType; import org.hibernate.type.Type; import java.io.Serializable; import java.math.BigDecimal; import java.math.BigInteger; import java.sql.PreparedStatement; import java.sql.ResultSet; import java.sql.SQLException; public class MyGenerator extends IdentityGenerator { @Override public InsertGeneratedIdentifierDelegate getInsertGeneratedIdentifierDelegate(final PostInsertIdentityPersister persister, final Dialect dialect, final boolean isGetGeneratedKeysEnabled) throws HibernateException { final InsertGeneratedIdentifierDelegate result; if(isGetGeneratedKeysEnabled) { result = new MyGetGeneratedKeysDelegate(persister, dialect); } else { result = super.getInsertGeneratedIdentifierDelegate(persister, dialect, isGetGeneratedKeysEnabled); } return result; } private static class MyGetGeneratedKeysDelegate extends GetGeneratedKeysDelegate { private final PostInsertIdentityPersister persister; private MyGetGeneratedKeysDelegate(final PostInsertIdentityPersister persister, final Dialect dialect) { super(persister, dialect); assert persister != null; this.persister = persister; } private Serializable getGeneratedIdentityByColumnName(ResultSet rs, Type type, String columnName) throws SQLException, HibernateException { if ( !rs.next() ) { throw new HibernateException( "The database returned no natively generated identity value" ); } final Serializable id = get(rs, type, columnName); // todo log.debug( "Natively generated identity: " + id ); return id; } private Serializable get(ResultSet rs, Type type, String columnName) throws SQLException, IdentifierGenerationException { if ( ResultSetIdentifierConsumer.class.isInstance( type ) ) { return ( ( ResultSetIdentifierConsumer ) type ).consumeIdentifier( rs ); } if ( CustomType.class.isInstance( type ) ) { final CustomType customType = (CustomType) type; if ( ResultSetIdentifierConsumer.class.isInstance( customType.getUserType() ) ) { return ( (ResultSetIdentifierConsumer) customType.getUserType() ).consumeIdentifier( rs ); } } Class<?> clazz = type.getReturnedClass(); if ( clazz == Long.class ) { return rs.getLong(columnName); } else if ( clazz == Integer.class ) { return rs.getInt(columnName); } else if ( clazz == Short.class ) { return rs.getShort(columnName); } else if ( clazz == String.class ) { return rs.getString( columnName ); } else if ( clazz == BigInteger.class ) { return rs.getBigDecimal( columnName ).setScale( 0, BigDecimal.ROUND_UNNECESSARY ).toBigInteger(); } else if ( clazz == BigDecimal.class ) { return rs.getBigDecimal( columnName ).setScale( 0, BigDecimal.ROUND_UNNECESSARY ); } else { throw new IdentifierGenerationException("unrecognised id type : " + type.getName() + " -> " + clazz.getName()); } } @Override public Serializable executeAndExtract(final PreparedStatement insert) throws SQLException { insert.executeUpdate(); ResultSet rs = insert.getGeneratedKeys(); try { final Type identifierType = persister.getIdentifierType(); Serializable result = null; boolean useDefaultTechnique = true; if(persister instanceof SingleTableEntityPersister) { final String[] idColumnNames = ((SingleTableEntityPersister)persister).getIdentifierColumnNames(); if(idColumnNames.length == 1) { // do it by column name result = getGeneratedIdentityByColumnName(rs, identifierType, idColumnNames[0] ); useDefaultTechnique = false; } else { // todo - log } } else { // todo - log } if(useDefaultTechnique) { result = IdentifierGeneratorHelper.getGeneratedIdentity(rs, identifierType); } return result; } finally { rs.close(); } } } } This seems to do the trick but is obviously an ugly hack. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-7068) "Cursor state not valid" error from AS400

by Alex Varakin (JIRA)

"Cursor state not valid" error from AS400 ----------------------------------------- Key: HHH-7068 URL: https://hibernate.onjira.com/browse/HHH-7068 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.0.0.Final Environment: -Hibernate version, shipped with AS 7.0.2 and 7.1.0RC1 -Database AS400 Reporter: Alex Varakin I am having a problem with an application which runs under AS 7.0.2 (7.1.0CR1 as well). It connects to database on AS400 using JPA interface and is able to read data from table on AS400 starting from row 0, but if I specify starting row more than 0 using query.setFirstResult, then I am getting an exception while running the actual query: Caused by: java.sql.SQLException: Cursor state not valid. at com.ibm.as400.access.JDError.createSQLExceptionSubClass(JDError.java:819) at com.ibm.as400.access.JDError.throwSQLException(JDError.java:411) at com.ibm.as400.access.JDError.throwSQLException(JDError.java:387) at com.ibm.as400.access.AS400JDBCResultSet.beforePositioning(AS400JDBCResultSet.java:1282) at com.ibm.as400.access.AS400JDBCResultSet.absolute(AS400JDBCResultSet.java:1086) at org.jboss.jca.adapters.jdbc.WrappedResultSet.absolute(WrappedResultSet.java:131) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_29] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_29] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_29] at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_29] at org.hibernate.engine.jdbc.internal.proxy.AbstractResultSetProxyHandler.continueInvocation(AbstractResultSetProxyHandler.java:104) [hibernate-core-4.0.0.Final.jar:4.0.0.Final] Same code works fine under AS 7.0.2 and Hibernate 3.6.9. I guess this is related to scrollable result set, it seems that Hibernate does not make result set as scrollable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-3307) HQL query translation in real SQL ignores the dialect class

by Thomas Schilf (JIRA)

HQL query translation in real SQL ignores the dialect class ----------------------------------------------------------- Key: HHH-3307 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3307 Project: Hibernate3 Issue Type: Bug Components: query-hql Affects Versions: 3.2.6 Environment: dialect file with special JoinFragment and a "transformSelectString" step Reporter: Thomas Schilf We're using a special dialect class for a database. In the dialect is defined a own JoinFragment and a "transformSelectString" step. All workes fine by loading objects over a Criteria class. The generated SQL string is wrong by using named queries (HQL). The SQL string is in normal ANSI-SQL. The SqlGenerator and QueryTranslatorImpl classes from hibernate don't use the dialect class. -- 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

12 years, 9 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-6507) Allow an Integrator to register additional types in the TypeRegistry

by Karel Maesen (JIRA)

Allow an Integrator to register additional types in the TypeRegistry -------------------------------------------------------------------- Key: HHH-6507 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6507 Project: Hibernate Core Issue Type: Task Components: core Reporter: Karel Maesen Other modules (e.g. Spatial) may define their own Types. The Module Integrator should be able to register these Types in the TypeRegistry. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
10
0 / 0

[Hibernate-JIRA] Created: (EJB-361) Query#setParameter(int position, Object value) wrong implementation

by Fabrice Daugan (JIRA)

Query#setParameter(int position, Object value) wrong implementation ------------------------------------------------------------------- Key: EJB-361 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-361 Project: Hibernate Entity Manager Issue Type: Bug Components: EntityManager Affects Versions: 3.3.2.GA Reporter: Fabrice Daugan The Hibernate JPA javax.persistence.Query#setParameter(int position, Object value) implementation does not suit to the JPA specicafication. Indeed, the actual integer passed to the operation is converted to String by Hibernate and then used to find the named parameter. Please have a look to the folowing stack trace : java.lang.Thread.run(Thread.java:619) Caused by: java.lang.IllegalArgumentException: org.hibernate.QueryParameterException: could not locate named parameter [1] at org.hibernate.ejb.QueryImpl.setParameter(QueryImpl.java:185) at org.hibernate.ejb.QueryImpl.setParameter(QueryImpl.java:240) at org.springframework.orm.jpa.JpaTemplate$9.doInJpa(JpaTemplate.java:316) To repoduce this error : -- 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

12 years, 9 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HV-423) Publish an API change report as part of the documentation

by Hardy Ferentschik (JIRA)

Publish an API change report as part of the documentation --------------------------------------------------------- Key: HV-423 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-423 Project: Hibernate Validator Issue Type: Improvement Components: documentation Affects Versions: 4.2.0.Beta1 Reporter: Hardy Ferentschik Fix For: 4.x These reports can be generated via JDiff or clirr. See also HV-417. -- 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

12 years, 9 months

2
6
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues February 2012