May 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (BVAL-189) Bean Validation should use java.beans.PropertyDescriptor

by Brian (JIRA)

Bean Validation should use java.beans.PropertyDescriptor -------------------------------------------------------- Key: BVAL-189 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-189 Project: Bean Validation Issue Type: Bug Affects Versions: 4.0.0.Alpha1 Environment: Any Reporter: Brian Priority: Minor Right now, hibernate determines a matching getter and setters by matching methods that start with "get" and "set" or "is" and "set". But the spec says that "is" should only be considered when the type is little boolean. Hibernate should fail validation in this case because it doesn't match the spec: public Boolean isVariable() public Boolean setVariable() because in this case "is" should be "get" since it is not a little boolean. -- 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

14 years, 1 month

3
5
0 / 0

[Hibernate-JIRA] Created: (BVAL-197) validation of a persisted map

by tho gau (JIRA)

validation of a persisted map ----------------------------- Key: BVAL-197 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-197 Project: Bean Validation Issue Type: Bug Environment: hibernate-core 3.5.0-Beta-3 Validator 4.0.1.GA MySQL 5.1 Reporter: tho gau Attachments: mapValidation.zip Hi, I am trying to validate an entity that holds a Map<K, V> of other persisted entities (just checking wether the map holds some predefined values). I can validate it "by hand" using validator.validate() and my map is correctly filled at validation time However when validation framework is called by persistence callbacks, my map is always empty... I am using Validator 4.0.1.GA and hibernate-core 3.5.0-Beta-2 I tryed to pinpoint the problem and it seems that the map is not touched in the following method of AbstractType during the merge : {code} public Object replace( Object original, Object target, SessionImplementor session, Object owner, Map copyCache, ForeignKeyDirection foreignKeyDirection) throws HibernateException { boolean include; if ( isAssociationType() ) { AssociationType atype = (AssociationType) this; include = atype.getForeignKeyDirection()==foreignKeyDirection; } else { include = ForeignKeyDirection.FOREIGN_KEY_FROM_PARENT==foreignKeyDirection; } return include ? replace(original, target, session, owner, copyCache) : target; } {code} -- 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

14 years, 1 month

4
14
0 / 0

[Hibernate-JIRA] Created: (HHH-2548) when "order by" a composit object, which may be null, the result list returns only when the composit objcts not null

by Yu Deng (JIRA)

when "order by" a composit object, which may be null, the result list returns only when the composit objcts not null -------------------------------------------------------------------------------------------------------------------- Key: HHH-2548 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2548 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.3 Environment: tomcat 5.5, eclipse3.2, jre1.5, postgreSQL8.1, hibernate3 and hibernate3.2 Reporter: Yu Deng Priority: Critical <hibernate-mapping package="com.grapevinecs.ams.domain.perbranch.inv"> <class name="InvItem"> <id name="id" column="id"> <generator class="hilo"/> </id> ... <many-to-one name="transferredDetails"/>  .... </class> (another mapping file) </hibernate-mapping>> <hibernate-mapping package="com.grapevinecs.ams.domain.perbranch.inv"> <class name="InvTransferDetails" > <id name="id" column="id"> <generator class="hilo"/> </id> <property name="returnedToICBC" type="com.grapevinecs.ams.dao.BooleanInteger" not-null="true"/> ... </class> </hibernate-mapping> Probelm: 1) The result returns 3000 records ---- select count(*) from InvItem c where upper(c.invType) LIKE '%D%' and c.invSeries.closed = '0' and c.branch =60551 order by c.transferredDetails.returnedToICBC asc, c.stamp asc,c.invNmbr asc 2) result List return size 0 by this query --- from InvItem c where upper(c.invType) LIKE '%D%' and c.invSeries.closed = '0' and c.branch =60551 order by c.transferredDetails.returnedToICBC asc, c.stamp asc,c.invNmbr asc 1) is correct but 2) is not correct. only when transferredDetails in InvItem not null be returned. in case 2), I have no transferredDetails not null. after I excuted the query 2), even I remove "c.transferredDetails.returnedToICBC asc", the result is still return nothing. -- 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

14 years, 1 month

3
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-321) FSSlaveDirectoryProvider incorrectly creates a subdirectory named 0

by Emmanuel Bernard (JIRA)

FSSlaveDirectoryProvider incorrectly creates a subdirectory named 0 ------------------------------------------------------------------- Key: HSEARCH-321 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-321 Project: Hibernate Search Issue Type: Bug Components: directory provider Reporter: Emmanuel Bernard Priority: Minor Fix For: 3.1.1 I see a few areas where 0 is set on current. It probably comes from that. -- 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

14 years, 2 months

3
6
0 / 0

[Hibernate-JIRA] Created: (ANN-640) use property names defined in CompositeUserType as default column names

by Michael Newcomb (JIRA)

use property names defined in CompositeUserType as default column names ----------------------------------------------------------------------- Key: ANN-640 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-640 Project: Hibernate Annotations Issue Type: New Feature Affects Versions: 3.3.0.ga Reporter: Michael Newcomb Priority: Minor Consider: public class LongitudeLatitude { protected double longitude; protected double latitude; } public class LongitudeLatitudeCompositeUserType implements CompositeUserType { public String[] getPropertyNames() { return new String[] { "longitude", "latitude" }; } public Type[] getPropertyTypes() { return new Type[] { Hibernate.DOUBLE, Hibernate.DOUBLE }; } ... } @Entity public class Test { @Basic(optional = false) @Type(type = "foo.bar.LongitudeLatitudeCompositeUserType") @Columns(columns = { @Column(name = "location_longitude"), @Column(name = "location_latitude") }) protected LongitudeLatitude location; } Why does the developer need to specify each column? I'd really rather let the CompositeUserType take care of that for me. Now, I have to tie the @Columns to the # of properties in my CompositeUserType AND the order in which they are defined? This seems to defeat the purpose of having a class (CompositeUserType) to tell Hibernate how to store it. Couldn't Hibernate prepend the property name 'location' and '_' to the front of each property name in the CompositeUserType? Perhaps (more than likely) I'm doing something wrong, but I get a failure if I do not specify the columns. Thanks, Michael -- 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

14 years, 2 months

6
16
0 / 0

[Hibernate-JIRA] Created: (HHH-2968) SimpleExpression.getTypedValues NullPointerException when ignoreCase and value==null

by Martijn Brinkers (JIRA)

SimpleExpression.getTypedValues NullPointerException when ignoreCase and value==null ------------------------------------------------------------------------------------ Key: HHH-2968 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2968 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.5 Reporter: Martijn Brinkers If ignoreCase is true and value is null a NullPointerException is thrown because toString() is called without checking for null. public TypedValue[] getTypedValues(Criteria criteria, CriteriaQuery criteriaQuery) throws HibernateException { Object icvalue = ignoreCase ? value.toString().toLowerCase() : value; return new TypedValue[] { criteriaQuery.getTypedValue(criteria, propertyName, icvalue) }; } -- 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

14 years, 2 months

4
3
0 / 0

[Hibernate-JIRA] Created: (BVAL-194) Invalid license info

by Stevo Slavic (JIRA)

Invalid license info -------------------- Key: BVAL-194 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-194 Project: Bean Validation Issue Type: Bug Affects Versions: 1.0 final Reporter: Stevo Slavic Priority: Minor validation-api-1.0.0.GA.pom declares Apache 2 as license but with invalid URL and license name is not standard. Please adjust license info in the pom to be as in [apache parent pom|http://repo1.maven.org/maven2/org/apache/apache/6/apache-6.pom] as this will improve how dependency to this project artifact is treated by all sorts of maven plug-ins and tools, like project info dependency report plugin, maven jboss license plugin, etc. So instead: {code} <licenses> <license> <name>Apache License, Version 2.0</name> <url>license.txt</url> </license> </licenses> {code} should be: {code} <licenses> <license> <name>The Apache Software License, Version 2.0</name> <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url> <distribution>repo</distribution> </license> </licenses> {code} -- 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

14 years, 2 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HV-280) Missing </code> element in Javadocs for ConstraintValidatorContext.ConstraintViolationBuilder.NodeContextBuilder

by Ed Burns (JIRA)

Missing </code> element in Javadocs for ConstraintValidatorContext.ConstraintViolationBuilder.NodeContextBuilder ---------------------------------------------------------------------------------------------------------------- Key: HV-280 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-280 Project: Hibernate Validator Issue Type: Bug Components: documentation Affects Versions: 4.0.2.GA Reporter: Ed Burns Assignee: Hardy Ferentschik Priority: Trivial ConstraintValidatorContext.ConstraintViolationBuilder.NodeContextBuilder - Interface in javax.validation Represent refinement choices for a node which is in an Iterator or Map. -- 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

14 years, 2 months

3
4
0 / 0

[Hibernate-JIRA] Created: (BVAL-206) Update pom to use the new distributationManagement information

by Hardy Ferentschik (JIRA)

Update pom to use the new distributationManagement information -------------------------------------------------------------- Key: BVAL-206 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-206 Project: Bean Validation Issue Type: Task Affects Versions: 1.0 final Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 1.1 This is just a build issue - http://community.jboss.org/wiki/MavenGettingStarted-Developers -- 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

14 years, 2 months

2
2
0 / 0

[Hibernate-JIRA] Created: (BVAL-201) Fix typo in spec, chapter 4.4.3

by Gunnar Morling (JIRA)

Fix typo in spec, chapter 4.4.3 ------------------------------- Key: BVAL-201 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-201 Project: Bean Validation Issue Type: Improvement Components: spec-general Affects Versions: 1.0 final Reporter: Gunnar Morling Priority: Trivial In chapter 4.4.3 (http://people.redhat.com/~ebernard/validation/#d0e4480), fourth paragraph, it should be "Such an implementation is useful to let a custom ConstraintValidatorFactory delegate to the standard ConstraintValidatorFactory." instead of "Such an implementation is useful to let a custom ConstraintValidatorFactory delegate to the standard TraversableResolver." -- 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

14 years, 2 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-471) Ability to "filter" entities from the search indexes

by Dobes Vandermeer (JIRA)

Ability to "filter" entities from the search indexes ---------------------------------------------------- Key: HSEARCH-471 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-471 Project: Hibernate Search Issue Type: New Feature Components: mapping Affects Versions: 3.1.1.GA Reporter: Dobes Vandermeer Priority: Minor In our system we have entities that are searched but not all of them are available for search - some of them are flagged as "removed". It would improve the efficiency of our search subsystem if we could implement a kind of "filter" that blocked these entities from being added to the search index, since we wouldn't have to make that a search term and our indexes would be somewhat smaller. -- 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

14 years, 2 months

5
31
0 / 0

[Hibernate-JIRA] Created: (HHH-4870) Cannot determine java-type from given member [null]

by Marcial Atienzar (JIRA)

Cannot determine java-type from given member [null] --------------------------------------------------- Key: HHH-4870 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4870 Project: Hibernate Core Issue Type: Bug Components: entity-manager Affects Versions: 3.5.0-Beta-4 Environment: jdk 6u18 glassfishv3 Reporter: Marcial Atienzar Attachments: eclipse.debug, Empre.java, Prcontra.java I've tested to migrate from hibernate 3.3.2 to 3.5.0 Beta4. I've remove all hibernate*.jar from classpath and add only de hibernate3.jar I've downloaded the source off hibernate-entitymanager to debug from eclipse. I've reached the class that has the error, but I don't know what can I do to resolve it. I'm doing something wrong? I attatch the sources of the classes that takes part on eclipse debug. I don't know how to attach a testcase. The project has more than 200 entities. I've post previously in hibernate forums: https://forum.hibernate.org/viewtopic.php?f=1&t=1002363&p=2424419#p2424419 -- 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

14 years, 2 months

9
60
0 / 0

[Hibernate-JIRA] Created: (HHH-2971) AbstractFlushingEventListener catches, logs and re-throws HibernateException in performExecutions generating noisy logs

by craig mcmillan (JIRA)

AbstractFlushingEventListener catches, logs and re-throws HibernateException in performExecutions generating noisy logs ----------------------------------------------------------------------------------------------------------------------- Key: HHH-2971 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2971 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Environment: v3.2.5 Reporter: craig mcmillan Priority: Minor AbstractFlushingEventListener catches HibernateException, logs an error, and re-throws the same HibernateException... so the Exception gets logged twice, or worse [ in the case i'm looking at, an offline locker ], an expected Exception [ConstraingViolationException] is caught and discarded, but an error is still logged -- 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

14 years, 2 months

13
15
0 / 0

[Hibernate-JIRA] Created: (HHH-2772) with-clause stopped working

by Ivo Danihelka (JIRA)

with-clause stopped working --------------------------- Key: HHH-2772 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2772 Project: Hibernate3 Issue Type: Bug Components: query-hql Affects Versions: 3.2.5, 3.2.4.sp1, 3.2.4, 3.2.3, 3.2.2 Reporter: Ivo Danihelka The with-clause stopped working in all hibernate versions above 3.2.1 (i.e. 3.2.2+). Before that, it was possible to write HQL: SELECT cat FROM Cat cat LEFT JOIN cat.kittens as kitten WITH kitten.owner=:owner Now the HQL is raising an exception: org.hibernate.hql.ast.InvalidWithClauseException: with clause can only reference columns in the driving table Workaround is to explicitly use primary key (ownerId): SELECT cat FROM Cat cat LEFT JOIN cat.kittens as kitten WITH kitten.owner.ownerId=:ownerId -- 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

14 years, 2 months

2
1
0 / 0

[Hibernate-JIRA] Created: (EJB-265) Incorrect SQL generated for JPA QL Update statement involving multiple entities

by Alex Savitsky (JIRA)

Incorrect SQL generated for JPA QL Update statement involving multiple entities ------------------------------------------------------------------------------- Key: EJB-265 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-265 Project: Hibernate Entity Manager Type: Bug Versions: 3.2.1 Environment: Hibernate 3.2.2 GA, Oracle 9i Reporter: Alex Savitsky When generating SQL for statements like this: UPDATE Issue i SET i.dueDate = i.dueDate + 10 WHERE i.visit.branch.id = :branchId, an extra comma is generated at the end of table list: update Issue, set DUE_DATE=DUE_DATE+10 where BRANCH_ID=? -- 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

14 years, 2 months

7
18
0 / 0

[Hibernate-JIRA] Created: (HHH-2965) When using Criteria.setResultTransformer(CriteriaSpecification.ALIAS_TO_ENTITY_MAP) method aliases need to be optional

by Ittai Zeidman (JIRA)

When using Criteria.setResultTransformer(CriteriaSpecification.ALIAS_TO_ENTITY_MAP) method aliases need to be optional ---------------------------------------------------------------------------------------------------------------------- Key: HHH-2965 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2965 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.2 Environment: 3.2.2 Oracle 10G Reporter: Ittai Zeidman Priority: Critical now when using the CriteriaSpecification- ALIAS_TO_ENTITY_MAP the convertion to map is using the aliases array, if it does not find an alias for the property it is not included in the map. I think that if no alias is defined then the propertyName attribute needs to be assigned as the key for the value in the hashmap. I came across this issue as i have many mapped entities in my system and when using projections i need to use the resultTransformer. this is critical as when using aliases it is duplicated not only to the select clause but to the where clause only which is another open bug (#HB-1331). If one bug is closed then the other can be considered as minor as i can give aliases to every property i need if it does not affect my where clause. -- 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

14 years, 2 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-85) Asynchronous incremental optimizer

by Emmanuel Bernard (JIRA)

Asynchronous incremental optimizer ---------------------------------- Key: HSEARCH-85 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-85 Project: Hibernate Search Issue Type: New Feature Components: directory provider Reporter: Emmanuel Bernard Priority: Minor The indexing process itself can be asynchronous, but if not, it would be nice to make the optimization process optionally asynchronous -- 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

14 years, 2 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-182) Use Directory getLockID() to uniquely identify a directory provider

by Emmanuel Bernard (JIRA)

Use Directory getLockID() to uniquely identify a directory provider ------------------------------------------------------------------- Key: HSEARCH-182 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-182 Project: Hibernate Search Issue Type: Improvement Components: directory provider Reporter: Emmanuel Bernard Priority: Minor Fix For: 3.1.0 Today the DirectoryProvider needs to implement equals and hashCode so that the underlying Directory is unique. We could delegate that to the directory.getLockID() which seem to fulfill the same contract. Not sure it works well with our lazy initialization strategy though. This needs to be checked out. -- 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

14 years, 2 months

2
2
0 / 0

[Hibernate-JIRA] Created: (ANN-862) Having to use @ForceDiscriminator kind of breaks JPA compatibility

by Albert Kurucz (JIRA)

Having to use @ForceDiscriminator kind of breaks JPA compatibility ------------------------------------------------------------------ Key: ANN-862 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-862 Project: Hibernate Annotations Issue Type: Improvement Affects Versions: 3.4.0.GA, 3.5, JPA 2.0 Environment: JPA Reporter: Albert Kurucz According to http://opensource.atlassian.com/projects/hibernate/browse/ANN-36 @ForceDiscriminator was created as a quick workaround to a problem. Yes, it solves the problem, but it creates a new problem: the source code which previously had only JPA annotations, now need to be annotated by a Hibernate annotation, causing that the the source code is now unable to use just any JPA provider. Major portability issue! Everyone who likes Open Source, hates Lock-Ins! My proposal: change the default to a more sane force=true, so that @ForceDiscriminator will not be needed for general JPA projects. (And create a @DisableDiscriminator Hibernate annotation, for those who like to brake their code). If changing default behavior is risky, don't fix this on older versions, but lets change this from 3.5.0-Beta2. -- 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

14 years, 2 months

5
38
0 / 0

[Hibernate-JIRA] Created: (HHH-3544) Nullability.checkNullability() throws PropertyValueException (not-null property references a null property) for a property that ForeignKeys.Nullifier.nullifyTransientReferences() just nulled

by Jeppe Cramon (JIRA)

Nullability.checkNullability() throws PropertyValueException (not-null property references a null property) for a property that ForeignKeys.Nullifier.nullifyTransientReferences() just nulled ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-3544 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3544 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Environment: Hibernate 3.3.1, Hibernate Annotations 3.4, Hibernate Commons-Annotation 3.3.1, Hibernate EntityManager 3.4, PostgreSQL 8.2.5, Java 5 Reporter: Jeppe Cramon Attachments: HibernateNullabilityProblem.zip Nullability.checkNullability throws PropertyValueException (not-null property references a null property) for a property that ForeignKeys.Nullifier.nullifyTransientReferences just nulled. I've included an Eclipse Java project which can reproduce the problem (didn't include the jars). The problem requires a pretty big graph to be reproduce able. The file "Domain Model.jpg" displays the Classes that take part in the problem. The Domain Model is a simplification of the entities from our application. In the example, ModelTest.java, there's only one active instance entity of each type (from A to H). With the given test case, when an instance of a is passed to entityManager.persist(..), then the following exception is thrown: javax.persistence.PersistenceException: org.hibernate.PropertyValueException: not-null property references a null or transient value: dk.hibernatetest.model.C.b at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:614) at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:226) at dk.hibernatetest.model.ModelTest.test(ModelTest.java:49) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:66) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: org.hibernate.PropertyValueException: not-null property references a null or transient value: dk.hibernatetest.model.C.b at org.hibernate.engine.Nullability.checkNullability(Nullability.java:95) at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:313) at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204) at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:144) at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49) at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154) at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110) at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:636) at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:628) at org.hibernate.engine.EJB3CascadingAction$1.cascade(EJB3CascadingAction.java:28) at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:291) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:239) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192) at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:319) at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:265) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:242) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192) at org.hibernate.engine.Cascade.cascade(Cascade.java:153) at org.hibernate.event.def.AbstractSaveEventListener.cascadeAfterSave(AbstractSaveEventListener.java:479) at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:357) at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204) at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:144) at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49) at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154) at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110) at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:636) at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:628) at org.hibernate.engine.EJB3CascadingAction$1.cascade(EJB3CascadingAction.java:28) at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:291) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:239) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192) at org.hibernate.engine.Cascade.cascade(Cascade.java:153) at org.hibernate.event.def.AbstractSaveEventListener.cascadeBeforeSave(AbstractSaveEventListener.java:454) at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:288) at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204) at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:144) at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49) at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154) at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110) at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:636) at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:628) at org.hibernate.engine.EJB3CascadingAction$1.cascade(EJB3CascadingAction.java:28) at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:291) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:239) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192) at org.hibernate.engine.Cascade.cascade(Cascade.java:153) at org.hibernate.event.def.AbstractSaveEventListener.cascadeBeforeSave(AbstractSaveEventListener.java:454) at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:288) at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204) at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:144) at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49) at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154) at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110) at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:636) at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:628) at org.hibernate.engine.EJB3CascadingAction$1.cascade(EJB3CascadingAction.java:28) at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:291) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:239) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192) at org.hibernate.engine.Cascade.cascade(Cascade.java:153) at org.hibernate.event.def.AbstractSaveEventListener.cascadeBeforeSave(AbstractSaveEventListener.java:454) at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:288) at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204) at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:144) at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49) at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154) at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110) at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:636) at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:628) at org.hibernate.engine.EJB3CascadingAction$1.cascade(EJB3CascadingAction.java:28) at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:291) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:239) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192) at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:319) at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:265) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:242) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192) at org.hibernate.engine.Cascade.cascade(Cascade.java:153) at org.hibernate.event.def.AbstractSaveEventListener.cascadeAfterSave(AbstractSaveEventListener.java:479) at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:357) at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204) at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:144) at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49) at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154) at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110) at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:61) at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:645) at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:619) at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:623) at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:220) ... 21 more As noted in TestModel.java, if some of the other entities (namely c, g or h) are passed to persist(), then the problem doesn't occur. I've tried to debug the problem and the only difference I've seen inside ForeignKeys.Nullifier.nullifyTransientReferences() is that, in the cases where an exception is thrown, then the B instance that C.b points to has the state SAVING, whereas when the exception isn't thrown, then it has state MANAGED. When the B instance has state SAVING, then ForeignKeys.Nullifier.nullifyTransientReferences() nulls then entry in it's value array. After that, Nullability.checkNullability(), performs a null check, which fails because ForeignKeys.Nullifier.nullifyTransientReferences() just nulled the property in the values array. Could it be a solution to reverse the order of the ForeignKeys.Nullifier.nullifyTransientReferences() and Nullability.checkNullability() (See AbstractEventListener.performSaveOrReplicate(...)) or does ForeignKeys.Nullifier.nullifyTransientReferences() instead have to take nullability into considerations? /Jeppe -- 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

14 years, 2 months

7
23
0 / 0

[Hibernate-JIRA] Created: (HHH-3910) Add support for custom dirty checking during flush

by Ovidio Mallo (JIRA)

Add support for custom dirty checking during flush -------------------------------------------------- Key: HHH-3910 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.3.1 Reporter: Ovidio Mallo Currently, Hibernate supports a special dirty checking on instrumented entities in order to improve the flush performance. IMO, this optimization can often be rather significant. However, the drawback is that you have to use bytecode instrumentation in order to take advantage of this performance improvement which might not be an option in some projects. Therefore, I wanted to propose to extend the current dirty checking during flush in such a way that the dirtyness information can also be directly provided by clients. Thereby, I could think of two possible approaches to do this: 1. Introduce an interface which client entities might implement in case they have some notion of dirtyness. The interface could look something like: public interface DirtyAwareEntity { boolean getMightBeDirty(); void setMightBeDirty(boolean mightBeDirty); } Using such an interface, Hibernate could easily check whether an entity might be dirty during flush and it could also reset the dirty flag after flush just as is currently done for instrumented classes. So this approach would probably be rather easy to implement and very convenient for clients since they would only have to implement that interface on the appropriate entities and set the dirty flag when the entity is actually modified. 2. Add some hooks on event listeners and/or on the Interceptor for querying whether an entity is dirty and for resetting the dirty flag. E.g. one could add the following hook method to the DefaultFlushEntityEventListener class: protected boolean requiresDirtyCheck(FlushEntityEvent event); By default, this method would call EntityEntry#requiresDirtyCheck(Object entity) as is done right now. Resetting the dirty flag could maybe be done in Interceptor#postFlush() or some dedicated method could be provided. BTW, I know that currently there already is the Interceptor#findDirty() method which already allows for some custom dirty checking but the problem from a performance point of view is that this method requires the entity's property values as parameter which are retrieved in DefaultFlushEntityEventListener#getValues() which is the most expensive method during flush. This drawback of the findDirty() method has often been noticed in comments on the news groups. I personally think it would be nice if something could be done to improve the performance of flushing in Hibernate since from what I read on the news groups and the like, flushing still seems to often lead to performance problems in practice, especially in larger projects where it is often not easy to avoid flushes or to keep the numer of entities in the session cache small. In fact, we are having quite some trouble with that in our project and having some custom dirty checking like the one I'm proposing here would greatly help in our project and in other projects as well, I guess. -- 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

14 years, 2 months

3
25
0 / 0

[Hibernate-JIRA] Created: (HHH-5024) MetadataContext#registerAttribute does not recognize inherited fields

by Adrian Hummel (JIRA)

MetadataContext#registerAttribute does not recognize inherited fields --------------------------------------------------------------------- Key: HHH-5024 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5024 Project: Hibernate Core Issue Type: Bug Components: entity-manager, metamodel Affects Versions: 3.5.0-CR-2 Environment: Hibernate 3.5.0-CR-2, JPA Modelgen 1.0.0-CR-1 Reporter: Adrian Hummel Priority: Critical Attachments: bugreport.zip The embeddable class {{CustomerId}} (see attached ZIP) inherits from the base class {{AbstractIdentity}} (annotated with {{@MappedSuperclass}}). The metamodel classes for these two classes are correctly generated: {code:title=AbstractIdentity_.java|borderStyle=solid} import javax.persistence.metamodel.SingularAttribute; import javax.persistence.metamodel.StaticMetamodel; @StaticMetamodel(AbstractIdentity.class) public abstract class AbstractIdentity_ { public static volatile SingularAttribute<AbstractIdentity, String> id; } {code} and {code:title=CustomerId_.java|borderStyle=solid} import javax.persistence.metamodel.StaticMetamodel; @StaticMetamodel(CustomerId.class) public abstract class CustomerId_ extends AbstractIdentity_ { } {code} When building the entity manager factory, {{MetadataContext#registerAttribute}} (line 378) tries to resolve the field {{CustomerId_.id}} using {{Class#getDeclaredField}}. This results in a {{NoSuchFieldException}} because the field is declared in the super class {{AbstractIdentity_}}. Proposed solution: Since all field declarations in the metamodel are public, the {{Class#getField}} method should be used instead. -- 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

14 years, 2 months

12
41
0 / 0

[Hibernate-JIRA] Created: (HHH-2879) consolidate approach for id and natural-id loading

by Steve Ebersole (JIRA)

consolidate approach for id and natural-id loading -------------------------------------------------- Key: HHH-2879 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2879 Project: Hibernate3 Issue Type: Improvement Reporter: Steve Ebersole Assignee: Steve Ebersole Currently, natural-id "loading' is only available through some incomplete criteria query hackery. Would like to expose a proper API for performing natural-id loading. In addition, would like this to be consolidated with the effort to cleanup the Session API and so have a unified way to load entities: Session.getLoader( MyEntity.class ).get( id ) Session.getNaturalIdLoader( MyEntity.class ).get( naturalId ) *DISCLAIMER : do not like the term 'loader' here because of ambiguity* -- 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

14 years, 2 months

2
16
0 / 0

[Hibernate-JIRA] Created: (HHH-3853) one-to-one mapping doesn support Primary Key Association

by Amar Singh (JIRA)

one-to-one mapping doesn support Primary Key Association -------------------------------------------------------- Key: HHH-3853 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3853 Project: Hibernate Core Issue Type: Bug Components: envers Environment: Hibernate - core 3.4.0-SNAPSHOT, Hibernate - envers (trunk build from today) Reporter: Amar Singh Attachments: one-to-one-pk.zip one-to-one mapping with primary key association doesn't seem to be working. Eg. Code: <?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> <hibernate-mapping package="org.hibernate.envers.test.integration.onetoone.bidirectional" default-lazy="false"> <class name="BidirectionalRefIngPK" table="BIDIRECTIONAL_REFERENCING_ENTITY"> <id name="id" type="long" column="BIDIRECTIONAL_REFERENCING_ID" > <generator class="foreign"> <param name="property">reference</param> </generator> </id> <property name="data"/> <property column="BIDIRECTIONAL_REFERENCING_ID" generated="never" insert="false" lazy="false" name="id" type="long" update="false"/> <one-to-one name="reference" cascade="save-update" class="BidirectionalRefEdPK" constrained="true" /> </class> <class name="BidirectionalRefEdPK" table="BIDIRECTIONAL_REFERENCED_ENTITY"> <id name="longId" type="long" column="BIDIRECTIONAL_REFERENCED_ID"> <generator class="native"/> </id> <property name="data"/> <one-to-one name="referencing" cascade="all" class="BidirectionalRefIngPK" /> </class> </hibernate-mapping> When we try to load a BidirectionalRefIngPK, the underlying query invokes RelatedAuditExpression and since its not a foreign-key based one-to-one association the loading fails in method addToQuery of RelatedAuditExpression at line 52 (relatedEntity==null) with the following exception: Code: "This criterion can only be used on a property that is a relation to another property." TO REPRODUCE ~~~~~~~~~~~~~ Please find a zip file attached which has four files: - BidirectionalPrimaryAssociation.java (actual testng test case) - BidirectionalRefEdPK.java (Entity 1) - BidirectionalRefIngPK.java (Entity 2) - mappings.hbm.xml Please put the three java files in its package (org.hibernate.envers.test.integration.onetoone.bidirectional) and the mapping file in src/test/resources. Now when you run envers tests you should see the failure. Thanks for this great component ! -- 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

14 years, 2 months

8
9
0 / 0

[Hibernate-JIRA] Created: (HHH-3414) fetch profiles

by Steve Ebersole (JIRA)

fetch profiles -------------- Key: HHH-3414 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414 Project: Hibernate3 Issue Type: New Feature Components: core, metamodel Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.4 The concept of fetch profiles as we are discussing here is basically to allow users to dynamically affect the mapped fetching strategy for associations at runtime. Consider the following example: <class name="Person"> ... <set name="addresses" lazy="true" fetch="subselect" ...> ... </set> </class> <class name="Address"> ... </class> This follows the normal recommendation to map associations as lazy and use a dynamic fetching strategy (ala HQL/Criteria) to modify this lazy behavior at runtime. The fetaure discussed here would allow the same behavior for loading as well: <hibernate-mapping> <fetch-profile name="person-details"> <fetch path="Person.addresses" style="join"/> </fetch-profile> </hibernate-mapping> Or: <hibernate-mapping> <class name="Person"> ... <fetch-profile name="person-details"> <fetch path="addresses" style="join"/> </fetch-profile> <set name="addresses" lazy="true" fetch="subselect" ...> ... </set> </class> </hibernate-mapping> Now, doing: session.enableFetchProfile( "person-details" ).get( Person.class, 1 )... will load Person#1 as well as their addresses in a single joined 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

14 years, 2 months

9
16
0 / 0

[Hibernate-JIRA] Created: (ANN-721) ManyToOne Persisting Cascade in Embeddable

by Endre Jeges (JIRA)

ManyToOne Persisting Cascade in Embeddable ------------------------------------------ Key: ANN-721 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-721 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.3.1.GA Environment: Java version: java version "1.6.0_04" Java(TM) SE Runtime Environment (build 1.6.0_04-b12) Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode, sharing) Oracle Version: Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production PL/SQL Release 9.2.0.8.0 - Production "CORE 9.2.0.8.0 Production" TNS for Linux: Version 9.2.0.8.0 - Production NLSRTL Version 9.2.0.8.0 - Production hibernate: 3.2.6.ga hibernate-annotations: 3.3.1.ga hibernate-commons-annotations: 3.3.0.ga hibernate-entitymanager: 3.3.1.ga Reporter: Endre Jeges Attachments: pairTest.zip Hello, I have found something that is a bit strange. For @ManyToOne association properties in an @Embeddable class the cascade PERSIST, SAVE-UPDATE option is not working well (not sure for the other cascade types), if the entities associated with ManyToOne are transient. I have created a unit test to check it and I have it attached to this issue. It is a maven2 project, and needs Oracle to run it. If I save the associated entites, then everything works fine, also the data structure is created well. I have checked the forums and found similar problems, maybe they can help more then my post: http://forum.hibernate.org/viewtopic.php?t=965238 http://forum.hibernate.org/viewtopic.php?t=976534 http://forum.hibernate.org/viewtopic.php?t=978112 http://forum.hibernate.org/viewtopic.php?t=978138 http://forum.hibernate.org/viewtopic.php?t=983766 http://forum.hibernate.org/viewtopic.php?t=983780 http://forum.hibernate.org/viewtopic.php?t=983868 Details: @Entity class CodedPairHolder { @Id private Long id; @Column(name = "CODE", nullable = false, unique = true, updatable = false, length = 256) private String code; @CollectionOfElements @JoinTable(name = "CODED_PAIR_HOLDER_PAIR_SET", joinColumns = @JoinColumn(name = "CODED_PAIR_HOLDER_ID")) private final Set<PersonPair> pairs = new HashSet<PersonPair>(0); ........ constructors getters equals hashCode } @Embeddable class PersonPair { @ManyToOne(optional = false, fetch = FetchType.LAZY, cascade = { CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH }) @Cascade( { org.hibernate.annotations.CascadeType.PERSIST, org.hibernate.annotations.CascadeType.MERGE, org.hibernate.annotations.CascadeType.REFRESH, org.hibernate.annotations.CascadeType.SAVE_UPDATE, org.hibernate.annotations.CascadeType.REPLICATE, org.hibernate.annotations.CascadeType.EVICT }) @JoinColumn(name = "LEFT_PERSON_ID", nullable = false, updatable = false) private Person left; @ManyToOne(optional = false, fetch = FetchType.LAZY, cascade = { CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH }) @Cascade( { org.hibernate.annotations.CascadeType.PERSIST, org.hibernate.annotations.CascadeType.MERGE, org.hibernate.annotations.CascadeType.REFRESH, org.hibernate.annotations.CascadeType.SAVE_UPDATE, org.hibernate.annotations.CascadeType.REPLICATE, org.hibernate.annotations.CascadeType.EVICT }) @JoinColumn(name = "RIGHT_PERSON_ID", nullable = false, updatable = false) private Person right; ........ constructors getters equals hashCode } @Entity class Person { @Id private Long id; @Column(name = "NAME", nullable = false, unique = true, updatable = false, length = 256) private String name; ........ constructors getters equals hashCode } The error message is: org.hibernate.TransientObjectException: object references an unsaved transient instance - save the transient instance before flushing: Person Regards, jeges -- 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

14 years, 2 months

7
16
0 / 0

[Hibernate-JIRA] Created: (HHH-2738) Eager fetch support for StatelessSession

by Christian Bauer (JIRA)

Eager fetch support for StatelessSession ---------------------------------------- Key: HHH-2738 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2738 Project: Hibernate3 Issue Type: Task Components: core Reporter: Christian Bauer class Node { @ManyToOne(fetch = FetchType.EAGER) @JoinColumn(name = "PARENT_NODE_ID", nullable = true) protected Node parent; } StatelessSession ss = getStatelessSession(); Node node = (Node) ss.get(Node.class, nodeId); [testng] org.hibernate.AssertionFailure: possible non-threadsafe access to the session [testng] at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:100) [testng] at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:854) [testng] at org.hibernate.loader.Loader.doQuery(Loader.java:729) [testng] at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236) [testng] at org.hibernate.loader.Loader.loadEntity(Loader.java:1860) [testng] at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48) [testng] at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42) [testng] at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3042) [testng] at org.hibernate.impl.StatelessSessionImpl.get(StatelessSessionImpl.java:158) [testng] at org.hibernate.impl.StatelessSessionImpl.get(StatelessSessionImpl.java:153) [testng] at org.hibernate.impl.StatelessSessionImpl.get(StatelessSessionImpl.java:145) -- 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

14 years, 3 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3674) Expose SchemaUpdate#haltOnError as a configuration property

by Chris Bredesen (JIRA)

Expose SchemaUpdate#haltOnError as a configuration property ----------------------------------------------------------- Key: HHH-3674 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3674 Project: Hibernate Core Issue Type: New Feature Components: documentation, metamodel Reporter: Chris Bredesen Assignee: Chris Bredesen Priority: Minor SchemaUpdate currently collects and logs any Exceptions caught during its work. While the Exceptions are logged, Hibernate is allowed to startup successfully. This feature request allows for a setting to flip this behavior such that Hibernate will not start if one or more Exceptions are encountered during SchemaUpdate (in test environments, of course). Proposed configuration option is hibernate.hbm2ddl.haltOnError -- 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

14 years, 3 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4713) Avoid using same cache instance for storing CacheValue and evictAll notifications

by Galder Zamarreno (JIRA)

Avoid using same cache instance for storing CacheValue and evictAll notifications --------------------------------------------------------------------------------- Key: HHH-4713 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4713 Project: Hibernate Core Issue Type: Bug Components: caching (L2) Affects Versions: 3.5.0-Beta-2 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 3.5 Store evictAll information in a separate infinispan cache instance in order to avoid doing stuff like this in BaseRegion.toMap which could be quite expensive in the context of SecondLevelCacheStatistics calculations: public Map toMap() { if (checkValid()) { // If copying causes issues, provide a lazily loaded Map Map map = new HashMap(); Set<Map.Entry> entries = cacheAdapter.toMap().entrySet(); for (Map.Entry entry : entries) { Object key = entry.getKey(); if (!CacheHelper.isEvictAllNotification(key)) { map.put(key, entry.getValue()); } } return map; } return Collections.EMPTY_MAP; } -- 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

14 years, 3 months

3
10
0 / 0

[Hibernate-JIRA] Created: (HHH-4694) Support "fake" many-to-one bidirectional relations

by Adam Warski (JIRA)

Support "fake" many-to-one bidirectional relations -------------------------------------------------- Key: HHH-4694 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4694 Project: Hibernate Core Issue Type: New Feature Components: envers Reporter: Adam Warski Assignee: Adam Warski Fix For: 3.5 Such relations are mapped with @OneToMany+@JoinColumn and @ManyToOne+@Column(insertable=false, updatable=false). This will be supported by an experimental @AuditMappedBy annotation. -- 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

14 years, 3 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3967) Great performance improvement for CascadingAction.PERSIST_ON_FLUSH action !!

by Guenther Demetz (JIRA)

Great performance improvement for CascadingAction.PERSIST_ON_FLUSH action !! ---------------------------------------------------------------------------- Key: HHH-3967 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3967 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.3.1 Environment: 3.3.1 GA , SQLServer Reporter: Guenther Demetz Sometimes large stateful transactions are unavoidable and especially when having several large persistent collections in dirty state, flushing becomes gradually more cpu intensive and slowly. Analizing several stacktraces I detected that the thread most time is executing at the same point in reflection , see here a typical stacktrace: java.lang.Class.isAssignableFrom(Native Method) sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:36) ... java.lang.reflect.Field.get(Field.java:358) DirectPropertyAccessor$DirectGetter.get(DirectPropertyAccessor.java:55) PojoEntityTuplizer(AbstractEntityTuplizer).getPropertyValue(Object, int) line: 300 SingleTableEntityPersister(AbstractEntityPersister).getPropertyValue(Object, int, EntityMode) line: 3609 Cascade.cascade(EntityPersister, Object, Object) line: 172 ... Making further investigations, I saw that: - CascadingAction.PERSIST_ON_FLUSH requires NoCascadeChecking - for all kind of properties the noCascade implementation is called - regarding noCascade implementation checks only properties of type Entity ! public static final CascadingAction PERSIST_ON_FLUSH = new CascadingAction() { ... public void noCascade(EventSource session, Object child, Object parent, EntityPersister persister, int propertyIndex) { ... Type type = persister.getPropertyTypes()[propertyIndex]; if ( type.isEntityType() ) { ... check and throw eventually a TransientObjectException } } Thus most property values are retrieved by reflection in vain as they are not of type entity. With following code addition in org.hibernate.engine.Cascade.java I was able do avoid most reflection method calls without affecting the behaviour: org.hibernate.engine.Cascade.java ... public void cascade(final EntityPersister persister, final Object parent, final Object anything) throws HibernateException { ... else if ( action.requiresNoCascadeChecking() ) { // Line:162 // begin Improvement if (action == CascadingAction.PERSIST_ON_FLUSH) { Type type = persister.getPropertyTypes()[i]; if ( !type.isEntityType() ) { // Remark: goes only well as long PERSIST_ON_FLUSH noCascade implementation checks only entities continue; } } // end Improvement action.noCascade( eventSource, persister.getPropertyValue( parent, i, entityMode ), parent, persister, i ); ... best regards Guenther D. -- 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

14 years, 3 months

2
8
0 / 0

[Hibernate-JIRA] Created: (HHH-5191) CollectionMetadataGenerator fails to obtain mappedBy attribute when is defined on superclasses

by Hernán Chanfreau (JIRA)

CollectionMetadataGenerator fails to obtain mappedBy attribute when is defined on superclasses ---------------------------------------------------------------------------------------------- Key: HHH-5191 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5191 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.5.1 Environment: Hibernate-envers build from branch_3_5 (3.5.2-SNAPSHOT) Reporter: Hernán Chanfreau When the inverse side on a bidirectional relation is defined on a superclass, envers fails to configure the mappedBy attribute because it doesn't search on superclasses. Here is the original discussion: http://community.jboss.org/thread/151240?tstart=0 I'm attaching two patcher. One contains 2 test cases and another with some modifications for this. Regards. Hernán. -- 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

14 years, 3 months

5
15
0 / 0

[Hibernate-JIRA] Created: (HHH-2125) Hibernate XML Mapping should not depend on dom4j

by Don Smith (JIRA)

Hibernate XML Mapping should not depend on dom4j ------------------------------------------------ Key: HHH-2125 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2125 Project: Hibernate3 Type: Improvement Components: core Versions: 3.2.0 cr1, 3.2.0.cr2, 3.2.0.cr3, 3.2.0.cr4 Environment: all Reporter: Don Smith Hibernate XML mapping requires dom4j, which is one of the packages that causes the Java version of "dll hell" - applications requiring conflicting versions of jars with no way to resolve the problem in a given release of an application server or package. HIbernate should be converted to use the standard XML APIs included in the JRE 5.0 specification, when Hibernate no longer needs to support JRE 1.4.x. -- 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

14 years, 3 months

6
10
0 / 0

[Hibernate-JIRA] Created: (HHH-3655) Select Query Using JPA and Static Inner Class

by Caine Lai (JIRA)

Select Query Using JPA and Static Inner Class --------------------------------------------- Key: HHH-3655 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3655 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.3.1 Environment: Hibernate Version 3.3.1 GA, using JPA. MySQL DB. Reporter: Caine Lai Attachments: HibernateStaticInnerClassBug.zip I want to collect some statistics using JPA and return them all as a value object to my web tier. In my value object I have a static inner class I would like to use for the JPA query. My Class: public class GeneralVendorStatsVO { private List<StatusCounts> statusCounts = new ArrayList<StatusCounts>(); /** * Inner class for holding status counts for vendors. */ public static class StatusCounts { private UserStatus status; private Long count; public StatusCounts(UserStatus status, Long count) { this.status = status; this.count = count; } public UserStatus getStatus() { return status; } public void setStatus(UserStatus status) { this.status = status; } public Long getCount() { return count; } public void setCount(Long count) { this.count = count; } } // ********************** Accessor Methods ********************** // public List<StatusCounts> getStatusCounts() { return statusCounts; } public void setStatusCounts(List<StatusCounts> statusCounts) { this.statusCounts = statusCounts; } } And here is the method I am trying to execute: public GeneralVendorStatsVO getGeneralVendorStats() { GeneralVendorStatsVO vo = new GeneralVendorStatsVO(); // Get the status counts. String queryString = "SELECT new vo.stats.vendor.GeneralVendorStatsVO.StatusCounts(user.status, count(user)) FROM User user GROUP BY user.status"; Query query = this.em.createQuery(queryString); List<GeneralVendorStatsVO.StatusCounts> statusCounts = query.getResultList(); vo.setStatusCounts(statusCounts); for (GeneralVendorStatsVO.StatusCounts entry : statusCounts) { log.debug("Status: " + entry.getStatus()+ "Count: " + entry.getCount()); } return vo; } The error: org.hibernate.hql.ast.QuerySyntaxException: Unable to locate class [vo.stats.vendor.GeneralVendorStatsVO.StatusCounts] I don't know why this would not work, when I can do: new GeneralVendorStatsVO.StatusCounts(UserStatus.APPROVED, 200L) I was told I should open an issue because it seems like a bug. More info here: http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=78... -- 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

14 years, 3 months

5
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2052) org.hibernate.pretty.MessageHelper.collectionInfoString tries to cast wrong object to String, causes ClassCastException

by Tree 'Huggy Bear' Hugger (JIRA)

org.hibernate.pretty.MessageHelper.collectionInfoString tries to cast wrong object to String, causes ClassCastException ----------------------------------------------------------------------------------------------------------------------- Key: HHH-2052 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2052 Project: Hibernate3 Type: Bug Reporter: Tree 'Huggy Bear' Hugger Attachments: bugtest.zip Debug level logging attempted by MessageHelper falls over when constructing a loggable string for a mapped collection on the main entity. Following the code in the stacktrace, I can see that MessageHelper expects the parent key for the collection relationship to be the primary key, but it is mapped to another field of a different type via a property-ref. Hence the ClassCastException below. The work around is to set logging to INFO or higher. I have also attached a pared-down zip with the maven 2 project containing the mappings and the unit test which fails. The following JIRA issue may be the same thing: http://opensource.atlassian.com/projects/hibernate/browse/ANN-298 The following messages on the Hib forum demonstrate other interest in this issue: http://forum.hibernate.org/viewtopic.php?t=949913 http://forum.hibernate.org/viewtopic.php?t=956778 http://forum.hibernate.org/viewtopic.php?t=962471 java.lang.ClassCastException: com.nomadsoft.cortex.domain.country.basic.BasicCountry at org.hibernate.type.StringType.toString(StringType.java:44) at org.hibernate.type.NullableType.toLoggableString(NullableType.java:168) at org.hibernate.pretty.MessageHelper.collectionInfoString(MessageHelper.java:284) at org.hibernate.loader.Loader.readCollectionElement(Loader.java:972) at org.hibernate.loader.Loader.readCollectionElements(Loader.java:635) at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:580) at org.hibernate.loader.Loader.doQuery(Loader.java:689) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224) at org.hibernate.loader.Loader.loadEntity(Loader.java:1785) at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:47) at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:41) at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:2730) at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:365) at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:346) at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:123) at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:177) at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:87) at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:862) at org.hibernate.impl.SessionImpl.get(SessionImpl.java:799) at org.hibernate.impl.SessionImpl.get(SessionImpl.java:792) at org.springframework.orm.hibernate3.HibernateTemplate$1.doInHibernate(HibernateTemplate.java:452) at org.springframework.orm.hibernate3.HibernateTemplate.execute(HibernateTemplate.java:366) at org.springframework.orm.hibernate3.HibernateTemplate.get(HibernateTemplate.java:446) at org.springframework.orm.hibernate3.HibernateTemplate.get(HibernateTemplate.java:440) at com.nomadsoft.cortex.infrastructure.hibernate.HibernateCountryRepository.getById(HibernateCountryRepository.java:26) at com.nomadsoft.cortex.domain.country.basic.BasicCountryService.getCountry(BasicCountryService.java:34) etc etc -- 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

14 years, 3 months

9
8
0 / 0

[Hibernate-JIRA] Created: (HHH-2515) Remove all documentation about HAR, it is deprecated

by Christian Bauer (JIRA)

Remove all documentation about HAR, it is deprecated ---------------------------------------------------- Key: HHH-2515 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2515 Project: Hibernate3 Type: Improvement Components: documentation Reporter: Christian Bauer Priority: Critical Clearly not one of the best ideas we ever had is the HAR deployment. It should now be considered deprecated (superseded by the EJB3/JPA deployment model) and any documentation about it should be removed. This includes JBoss AS user guides, wiki pages, etc. If you have any objects and think that HAR is a fantastic thing, raise them here. -- 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

14 years, 3 months

4
11
0 / 0

[Hibernate-JIRA] Created: (HHH-4550) query cache: Attention with configuring Update Timestamps Cache region: expired entries cause wrong result sets!

by Guenther Demetz (JIRA)

query cache: Attention with configuring Update Timestamps Cache region: expired entries cause wrong result sets! ---------------------------------------------------------------------------------------------------------------- Key: HHH-4550 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4550 Project: Hibernate Core Issue Type: Improvement Components: caching (L2) Affects Versions: 3.3.2 Environment: 3.3.2 GA Reporter: Guenther Demetz Priority: Trivial Attachments: TestCaseQuryCache.jar When using hibernate's query cache (hibernate.cache.use_query_cache), then it's of fundamental importance to configure the Update Timestamps cache region in a way that his entries survive longer than the cached result sets in the Query cache region. Otherwise queries could return wrong (obsolete) result sets (See attached testcase). This is because the current UpdateTimestampsCache#isUpToDate implementation considers a result-set also as up-to-date, if there are no update-timestamps cached for the interested spaces (tables) at all. It if therefore important to notice that: 1- The Update-Timestamps-Cache-Region elements max-size should be configured higher than the number of tables you have on the db-schema, in manner that he can remember/hold the last update-timestamp for each table. 2- If you use any other eviction policy in the Update-Timestamps-Cache-Region, then you must assure that cached result sets in the Query-cache-region are evicted before relevant update-timestamps are going to be evicted. This fact should be clearly documented somewhere. Thanks G.D. -- 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

14 years, 3 months

4
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3892) Improve support for mapping SQL LONGVARCHAR and CLOB to Java String, SQL LONGVARBINARY and BLOB to Java byte[]

by Gail Badner (JIRA)

Improve support for mapping SQL LONGVARCHAR and CLOB to Java String, SQL LONGVARBINARY and BLOB to Java byte[] --------------------------------------------------------------------------------------------------------------- Key: HHH-3892 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3892 Project: Hibernate Core Issue Type: Improvement Components: core Reporter: Gail Badner Assignee: Gail Badner Fix For: 3.2.x, 3.3.x, 3.5 Property types will be provided to enable an application to process data for a java.sql.Types.LONGVARCHAR or java.sql.Types.CLOB column as a Java String. Hibernate will internally process the data as a streams. On a read, stream data will immediately be materialized into a Java string. text - property type to map java.sql.Types.LONGVARCHAR column data as a Java String (via org.hibernate.type.TextType); (NOTE: currently, org.hibernate.type.TextType incorrectly maps "text" to java.sql.Types.CLOB; this will be fixed by this issue and updated in database dialects) materialized_clob - property type to map java.sql.Types.CLOB column data as a Java String (via org.hibernate.type.MaterializedClobType); In addition, new property types will be provided to enable an application to process data for a java.sql.Types.LONGVARBINARY or java.sql.Types.BLOB column as Java byte[]. Hibernate will internally process the data as a streams. On a read, stream data will immediately be materialized into a Java byte[]. image - property type to map java.sql.Types.LONGVARBINARY column data as byte[] (via org.hibernate.type.ImageType); materialized_blob - property type to map java.sql.Types.BLOB column data as byte[] (via org.hibernate.type.MaterializedBlobType); -- 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

14 years, 3 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HHH-4555) Support use of Envers with Auto-commit mode.

by Kevin Schmidt (JIRA)

Support use of Envers with Auto-commit mode. -------------------------------------------- Key: HHH-4555 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4555 Project: Hibernate Core Issue Type: New Feature Components: envers Affects Versions: 3.5.0-Beta-2 Environment: Hibernate 3.5.0-Beta-2 Reporter: Kevin Schmidt Currently Envers is designed so that it synchronizes with the currently running transaction in order to know when to commit the inserts into the Audit Tables. This is an effective strategy for ensuring that the audit information is only saved to the database if the Transactional Unit of Work which caused the audit data to be created is committed. This design creates a limitation on Envers such that it cannot persist audit information unless there is an active transaction. This effectively disables auditing for anyone modifying data using Hibernate outside of a Hibernate Transaction. Specifically, if you are using Autocommit = True and manually flushing the Hibernate Session then you cannot have any of your data audited using Envers. I am not that well versed with the design of Envers but was hoping this situation could be detected and avoided. Maybe the audit information could be synchronized on the flush event rather than when a transaction is committed to 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

14 years, 3 months

3
11
0 / 0

[Hibernate-JIRA] Created: (HHH-3383) QueryKey is storing references to entities instead of identifiers

by Manuel Dominguez Sarmiento (JIRA)

QueryKey is storing references to entities instead of identifiers ----------------------------------------------------------------- Key: HHH-3383 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3383 Project: Hibernate3 Issue Type: Improvement Components: caching (L2) Affects Versions: 3.3.0.CR1 Environment: ehcache 1.5.0b2 Reporter: Manuel Dominguez Sarmiento Context: query caching Hibernate is storing full entity references when building QueryKeys and the query has restrictions which reference entities. This happens either with Criteria or HQL queries. Although this is not incorrect, when the referenced entities reference in turn "heavy" object graphs, this causes a very significant memory usage increase, since references to detached entities will remain in the cache. This is even more evident when using disk persistence with ehcache, since the full object graphs are serialized to disk. This could be easily improved (correct me if I'm wrong) by storing ONLY entity identifiers in the QueryKey instead of full entities, since all the query really needs is the identifier property. The memory usage would decrease dramatically. So far the workaround we've found is explicitly using restrictions that reference identifiers instead of properties in HQL queries, however this is not particularly elegant, and still leaves open the issue with Criteria queries. The same cannot be done without criteria.createCriteria() which generates an unnecessary join in most cases. -- 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

14 years, 3 months

6
10
0 / 0

[Hibernate-JIRA] Created: (HHH-2896) unified approach for id and natural-id loading

by Steve Ebersole (JIRA)

unified approach for id and natural-id loading ----------------------------------------------- Key: HHH-2896 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2896 Project: Hibernate3 Issue Type: Improvement Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole A follow-on to HHH-2879 in regards to unifying the loading of entities by pk or natural-id. -- 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

14 years, 3 months

3
21
0 / 0

[Hibernate-JIRA] Created: (HHH-5275) Criteria.setLockMode does not work correctly

by Björn Moritz (JIRA)

Criteria.setLockMode does not work correctly -------------------------------------------- Key: HHH-5275 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.2 Environment: Hibernate 3.5.2, Oracle 10 (using org.hibernate.dialect.Oracle10gDialect Reporter: Björn Moritz Priority: Minor Attachments: TestCase.zip The LockMode set via Criteria.setLockMode does not generate a ' for update' SQL statement. In the org.hibernate.dialect.Dialect class only the LockOptions are used for determining a possible addition to the SQL statement if using pessimistic locking. This behaviour is different from Hibernate 3.1.3. In the supplied TestCase two threads are reading the same database record; one of those threads should use pessimistic locking thereby blocking the other thread. But both threads can read the database record causing the test to fail. -- 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

14 years, 3 months

8
43
0 / 0

[Hibernate-JIRA] Created: (HHH-2763) (lazy) m:n relation + EventListener = AssertionFailure: collection [n-side] was not processed by flush()

by S.Schnabl (JIRA)

(lazy) m:n relation + EventListener = AssertionFailure: collection [n-side] was not processed by flush() -------------------------------------------------------------------------------------------------------- Key: HHH-2763 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5, 3.2.4.sp1 Environment: Windows-XP, Jboss 4.2.1GA, Hibernate 3.2.4SP1, EJB3 Reporter: S.Schnabl Priority: Critical Attachments: Testcase.zip For more details see the attached testcase. I'm sorry, but in the short of time i only got a testcase for jboss-server 4.2. Please deploy the server.ear from /release-directory and then call the /src/client/TestCaseClient.java. [Summarized] It seems, that touching a lazy (Persistent-)Collection of at least a m:n relation inside a Hibernate event-listener always raises this error: org.hibernate.AssertionFailure: collection [n-side] was not processed by flush() [Explanation] I have two entities A. and B. Both having a m:n relation between each other. Furthermore there is an PostUpdateListener, which iterates onUpdate of entitiy through all properties of updated entity. [Testcase] Both entities are linked with eachother (m:n). If i now do a simple update of a property of entity A --> MyPostUpdateListener will be called, which iterates through every property of the updated entity. In case of this property was a collection (= lazy PersistentCollection of m:n relation), hibernate initializes the collection for further work. I can now run through all objects of the collection, but after all work is done in listener, I get the following exception from postFlush: Caused by: org.hibernate.AssertionFailure: collection [com.qualitype.testcase.server.ejb.entity.EntityB.entitiesOfA] was not processed by flush() at org.hibernate.engine.CollectionEntry.postFlush(CollectionEntry.java:205) at org.hibernate.event.def.AbstractFlushingEventListener.postFlush(AbstractFlushingEventListener.java:333) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:28) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338) at org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:515) ... 29 more Attention: EntityB.entitiesOfA is the other-side collection of the m:n relation of the updated EntityA. We are using hibernate-event listener system for auditing-purposes, so you should understand that touching every (element in the) collection is necessary for audit-purposes. Seems for me like a serious bug. Need this fixed asap ... -- 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

14 years, 3 months

32
59
0 / 0

[Hibernate-JIRA] Created: (HHH-4439) In general it is impossible to override properties defined in @MappedSuperclass to change how they will be handled during auditing.

by Eugene Goroschenya (JIRA)

In general it is impossible to override properties defined in @MappedSuperclass to change how they will be handled during auditing. ----------------------------------------------------------------------------------------------------------------------------------- Key: HHH-4439 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4439 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.5.0.Beta-1, 3.3.2, 3.2.x, 3.5 Reporter: Eugene Goroschenya Priority: Critical It seems there are several use cases with this issue but most important for me is @MappedSuperclass class A { @Audited private String value; } @Entity @Audited class MyAutided extends A { } @Entity class MyNotAutided extends A { } I need MyNotAutided is not audited at all (there is not MyNotAutided_AUD table and MyNotAutided revisions are not created) nut seems it is impossible because use case above leads to creating MyNotAutided_AUD table and creating of revisions for MyNotAutided. I assume @AuditOverride must support it to say that MyNotAutided.value is not audited but it doesn't work. -- 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

14 years, 3 months

4
4
0 / 0

[Hibernate-JIRA] Created: (HHH-5257) @JoinTable results in redundant join in the generated SQL

by Sharath Reddy (JIRA)

@JoinTable results in redundant join in the generated SQL --------------------------------------------------------- Key: HHH-5257 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5257 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.2 Reporter: Sharath Reddy Priority: Minor Fix For: 3.6 Attachments: testcase.zip An Account can have several Clients: @Entity @Table(name = "CLIENT") public class Client implements Serializable { private String street; private String code; private String city; @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private int id; @ManyToOne @JoinTable(name = "CLIENT_ACCOUNT", joinColumns = {@JoinColumn(name = "FK_CLIENT", referencedColumnName = "ID")}, inverseJoinColumns = {@JoinColumn(name = "FK_ACCOUNT", referencedColumnName = "ID")}) private Account account; ..... } @Entity @Table(name = "ACCOUNT") public class Account implements Serializable { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private int id; private String number; private double balance; @OneToMany (fetch = FetchType.EAGER, mappedBy="account") private Set<Client> holders; ... } When we load the Account entity: Account a1 = (Account) session.load(Account.class, accountId); We see that there is a redundant join at the end - from the CLIENT table to the CLIENT_ACCOUNT table: select account0_.id as id2_1_, account0_.balance as balance2_1_, account0_.number as number2_1_, holders1_.FK_ACCOUNT as FK1_2_3_, client2_.id as FK2_3_, client2_.id as id0_0_, client2_.city as city0_0_, client2_.code as code0_0_, client2_.street as street0_0_, client2_1_.FK_ACCOUNT as FK1_1_0_ from ACCOUNT account0_ left outer join CLIENT_ACCOUNT holders1_ on account0_.id=holders1_.FK_ACCOUNT left outer join CLIENT client2_ on holders1_.FK_CLIENT=client2_.id left outer join CLIENT_ACCOUNT client2_1_ on client2_.id=client2_1_.FK_CLIENT where account0_.id=? -- 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

14 years, 3 months

5
22
0 / 0

[Hibernate-JIRA] Created: (HHH-2511) generated="insert/always" ignored for property in composite-element?

by James Garrison (JIRA)

generated="insert/always" ignored for property in composite-element? -------------------------------------------------------------------- Key: HHH-2511 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2511 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.2 Environment: Hibernate 3.2.2, Windows XP SP2, Oracle 9i Reporter: James Garrison Priority: Minor I have a composite-element (in an idbag) that has a db-generated timestamp property. I have defined the property with update="false" insert="false" generated="insert", but Hibernate is trying to insert a null value when saving a transient object. See below, the "createTs" property (column=CREATE_TS) in the "comments" composite-element. DDL: create table CR_COMMENT ( COMMENT_ID integer not null, REQ_ID integer not null, CREATE_TS timestamp default sysdate not null, SECTION_ID char(1) not null, USER_ID varchar2(20) not null, TEXT varchar2(4000) not null, primary key(COMMENT_ID), foreign key(REQ_ID) references CR_REQUEST (REQ_ID) on delete cascade ); Mapping: <?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> <hibernate-mapping package="com.wholefoods.ittoolkit.ws.ccf"> <class name="Request" table="CR_REQUEST"> <id name="reqId" column="REQ_ID" type="long"> <generator class="sequence"> <param name="sequence">CR_REQUEST_ID</param> </generator> </id> [snip] <idbag name="comments" table="CR_COMMENT"> <collection-id type="long" column="COMMENT_ID"> <generator class="sequence"> <param name="sequence">CR_COMMENT_ID</param> </generator> </collection-id> <key column="REQ_ID" /> <composite-element class="Comment"> <property name="createTs" column="CREATE_TS" type="calendar" access="field" update="false" insert="false" generated="insert" /> <property name="sectionId" column="SECTION_ID" /> <property name="userId" column="USER_ID" /> <property name="text" column="TEXT"/> </composite-element> </idbag> </class> </hibernate-mapping> Log Output: Hibernate: /* insert collection row com.wholefoods.ittoolkit.ws.ccf.Request.comments */ insert into ITTOOLKIT.CR_COMMENT (REQ_ID, COMMENT_ID, CREATE_TS, SECTION_ID, USER_ID, TEXT) values (?, ?, ?, ?, ?, ?) 10:15:01,659 DEBUG org.hibernate.jdbc.AbstractBatcher:476 - preparing statement 10:15:01,675 DEBUG org.hibernate.type.LongType:133 - binding '47' to parameter: 1 10:15:01,675 DEBUG org.hibernate.type.LongType:133 - binding '7' to parameter: 2 10:15:01,675 DEBUG org.hibernate.type.CalendarType:126 - binding null to parameter: 3 10:15:01,675 DEBUG org.hibernate.type.StringType:133 - binding 'A' to parameter: 4 10:15:01,690 DEBUG org.hibernate.type.StringType:133 - binding 'garrisoj' to parameter: 5 10:15:01,690 DEBUG org.hibernate.type.StringType:133 - binding 'This is a test comment' to parameter: 6 10:15:01,690 DEBUG org.hibernate.persister.collection.AbstractCollectionPersister:1172 - done inserting collection: 1 rows inserted 10:15:01,690 DEBUG org.hibernate.jdbc.AbstractBatcher:44 - Executing batch size: 1 10:15:01,737 DEBUG org.hibernate.jdbc.AbstractBatcher:366 - about to close PreparedStatement (open PreparedStatements: 1, globally: 1) 10:15:01,737 DEBUG org.hibernate.jdbc.AbstractBatcher:525 - closing statement 10:15:01,768 DEBUG org.hibernate.util.JDBCExceptionReporter:69 - Could not execute JDBC batch update [/* insert collection row com.wholefoods.ittoolkit.ws.ccf.Request.comments */ insert into ITTOOLKIT.CR_COMMENT (REQ_ID, COMMENT_ID, CREATE_TS, SECTION_ID, USER_ID, TEXT) values (?, ?, ?, ?, ?, ?)] java.sql.BatchUpdateException: ORA-01400: cannot insert NULL into ("ITTOOLKIT"."CR_COMMENT"."CREATE_TS") -- 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

14 years, 3 months

6
11
0 / 0

[Hibernate-JIRA] Created: (HHH-3820) Criterion should implement equals and hashCode

by Craig (JIRA)

Criterion should implement equals and hashCode ---------------------------------------------- Key: HHH-3820 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3820 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.2.6 Reporter: Craig .equals() doesn't work as expected for Criterion and its subclasses. For example: assertEquals(Restrictions.isEmpty("parents"),Restrictions.isEmpty("parents")); fails, when clearly, it should work. -- 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

14 years, 3 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2455) "Could not close a JDBC result set" output very often

by Dirk Feufel (JIRA)

"Could not close a JDBC result set" output very often ----------------------------------------------------- Key: HHH-2455 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.2 Reporter: Dirk Feufel Priority: Minor If you call this type of code (like the DbTimestampType class does), the AbstractBatcher outputs a warning "Could not close a JDBC result set". The problem should be that closing the prepared statement internally also closes the associated result sets and the AbstractBatcher still has a reference to this result set. One possible solution might be to provide an additional method public void closeStatement(PreparedStatement ps, ResultSet rs); (as already present for closeQueryStatement) in the AbstractBatcher allowing to close both in the right order. PreparedStatement ps = null; try { ps = session.getBatcher().prepareStatement( timestampSelectString ); ResultSet rs = session.getBatcher().getResultSet( ps ); .... } finally { if ( ps != null ) { session.getBatcher().closeStatement( ps ); } } -- 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

14 years, 3 months

4
17
0 / 0

[Hibernate-JIRA] Created: (HHH-5124) Removing an entity and persisting it again fails

by Jesper Steen Møller (JIRA)

Removing an entity and persisting it again fails ------------------------------------------------ Key: HHH-5124 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5124 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.x, 3.5.x Environment: Tested with Hibernate 3.3.2, HSQL 1.7.2 Reporter: Jesper Steen Møller Attachments: RemoveAndPersistProblem.zip According to the JPA spec section 3.2.1, it should be possible to remove and then (re)persist an entity, but Hibernate will throw an javax.persistence.EntityNotFoundException: deleted entity passed to persist, originating from DefaultPersistEventListener.onPersist, in the 'default'-case of the switch for entityState. The code in question is not changed between 3.3.2 and 3.5.1, so it should have the same problem. The enclosed test project (Eclipse project format, just add all the usual jars + hsql) demonstrates the problem. Also see https://forum.hibernate.org/viewtopic.php?f=1&t=995703&view=previous -- 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

14 years, 4 months

3
24
0 / 0

[Hibernate-JIRA] Created: (HCANN-9) Unable to reference JPA entity beans in a different package

by Krashan Brahmanjara (JIRA)

Unable to reference JPA entity beans in a different package ----------------------------------------------------------- Key: HCANN-9 URL: http://opensource.atlassian.com/projects/hibernate/browse/HCANN-9 Project: Hibernate Commons Annotations Issue Type: Bug Environment: Hibernate Annotations 3.4.0.GA in Jboss 5.1.0.GA Reporter: Krashan Brahmanjara Problem described in https://forum.hibernate.org/viewtopic.php?f=1&t=998404 Example Two classes test.jpa.db1.Card ant test.jpa.db2.Cards are in different packages in the same jar and @ManyToOne fails if deployed on Jboss server ... but it work if these clases are together in the same package. ... it not fails on Weblogic with OpenJpa Stack trace 09:53:37,609 ERROR [AbstractKernelController] Error installing to Start: name=persistence.unit:unitName=test-services-ear .ear/test-services-ejb-3.0.alfa-SNAPSHOT.jar#test-services-jpa state=Create org.hibernate.AnnotationException: @OneToOne or @ManyToOne on test.jpa.db1.Card.podm references an unknown ent ity: test.jpa.db2.Cards at org.hibernate.cfg.ToOneFkSecondPass.doSecondPass(ToOneFkSecondPass.java:81) at org.hibernate.cfg.AnnotationConfiguration.processEndOfQueue(AnnotationConfiguration.java:456) at org.hibernate.cfg.AnnotationConfiguration.processFkSecondPassInOrder(AnnotationConfiguration.java:438) at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:309) at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1148) at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1226) at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:173) at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:854) at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:425) at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:131) at org.jbtest.jpa.deployment.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:301) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jbtest.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59) at org.jbtest.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150) Tested workarounds, both doesn't work: - adding an orm.xml file with entries like: <entity>test.jpa.db1.Card</entity> <entity>test.jpa.db2.Cards</entity> - adding an hibernate extensions to class definition like: @Entity @org.hibernate.annotations.Entity @Table(name = "card") public class Card implements Serializable { -- 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

14 years, 4 months

5
9
0 / 0

[Hibernate-JIRA] Created: (HHH-2907) ability to apply 'generation strategy' to generated properties

by Steve Ebersole (JIRA)

ability to apply 'generation strategy' to generated properties -------------------------------------------------------------- Key: HHH-2907 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2907 Project: Hibernate3 Issue Type: New Feature Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Priority: Minor Fix For: 3.3 Currently, the support for generated properties allows only for db-generated values (ala triggers etc). Would be great to allow the user to provide a seperate (optional) strategy for generating the generated values. It would be nice to have a generic solution, which we can build on top of for the more common use cases. Also, we may need to use a name other than 'generated' in the annotations to avoid conflicts with the current @Generated annotation; for now lets use the term @Dynamic. Consider mapping a 'created timestamp' column. Currently, provided we are using a trigger, that would look like: @Generated(INSERT) Date created; The strategy here (^^) is implicitly 'db', as the db is taking care of the generation. In the most generic form, that could be written as: @Dynamic(time=INSERT,strategy=DB) Date created; Additionally, since this is such a common case, also allow this: @CreationTimestamp Date created; The final form would also allow the definition of strategies. As an example, consider: @CreationTimestamp(strategy=NOW) Date created; Here we are not relying on the db to generate the value, but are explicitly telling Hibernate to do it (basically 'use the current timestamp to generate a value here whenever we do an insert'). -- 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

14 years, 4 months

2
8
0 / 0

[Hibernate-JIRA] Created: (HHH-4521) Hibernate/Infinispan integration doesn't property handle Entity/CollectionRegionAccessStrategy evict(Object)

by Galder Zamarreno (JIRA)

Hibernate/Infinispan integration doesn't property handle Entity/CollectionRegionAccessStrategy evict(Object) ------------------------------------------------------------------------------------------------------------ Key: HHH-4521 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4521 Project: Hibernate Core Issue Type: Bug Components: caching (L2) Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 3.5 Port HHH-4517 to Infinispan second level cache integration. -- 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

14 years, 4 months

3
12
0 / 0

[Hibernate-JIRA] Created: (HHH-4048) Phase 2 - implement rest of strategies

by Steve Ebersole (JIRA)

Phase 2 - implement rest of strategies -------------------------------------- Key: HHH-4048 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4048 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

14 years, 4 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-3800) Allow chopping of class names in various logging scenarios

by Steve Ebersole (JIRA)

Allow chopping of class names in various logging scenarios ---------------------------------------------------------- Key: HHH-3800 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3800 Project: Hibernate Core Issue Type: Improvement Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Priority: Minor When logging enti ty class names, it would be nice to allow "collapsing" or "stripping" the entity name in various ways. Or when referencing Hibernate 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

14 years, 4 months

1
6
0 / 0

[Hibernate-JIRA] Created: (HHH-5223) Allow 2-phase load of components

by Steve Ebersole (JIRA)

Allow 2-phase load of components -------------------------------- Key: HHH-5223 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5223 Project: Hibernate Core Issue Type: Improvement Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.6 -- 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

14 years, 4 months

1
3
0 / 0

[Hibernate-JIRA] Created: (HHH-5037) Improve documentation for immutable/read-only entity and immutable collection functionality

by Gail Badner (JIRA)

Improve documentation for immutable/read-only entity and immutable collection functionality ------------------------------------------------------------------------------------------- Key: HHH-5037 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5037 Project: Hibernate Core Issue Type: Improvement Components: documentation Reporter: Gail Badner Assignee: Gail Badner Fix For: 3.5.0.Next -- 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

14 years, 4 months

3
14
0 / 0

[Hibernate-JIRA] Created: (HHH-4814) Improve IsolatedClassloaderTest so that primary key is also custom

by Galder Zamarreno (JIRA)

Improve IsolatedClassloaderTest so that primary key is also custom ------------------------------------------------------------------ Key: HHH-4814 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4814 Project: Hibernate Core Issue Type: Task Components: caching (L2) Affects Versions: 3.5.0-Beta-3 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 3.5.0-Beta-4 Improve IsolatedClassloaderTest and corresponding entities so that not only a custom type if used in the query as parameter, but the entity's primary key is also a custom type. http://lists.jboss.org/pipermail/jboss-development/2010-January/015466.html -- 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

14 years, 4 months

3
9
0 / 0

[Hibernate-JIRA] Created: (HHH-4759) Create unit test for flush/rollback issue when JDBCTransactionFactory in use with Infinispan

by Galder Zamarreno (JIRA)

Create unit test for flush/rollback issue when JDBCTransactionFactory in use with Infinispan -------------------------------------------------------------------------------------------- Key: HHH-4759 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4759 Project: Hibernate Core Issue Type: Task Components: caching (L2) Affects Versions: 3.5.0-Beta-2 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Priority: Minor Fix For: 3.5 Create a UT that replicates what's being reported here when JDBC transaction factory is in use: http://community.jboss.org/message/517376#517376 -- 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

14 years, 4 months

3
10
0 / 0

[Hibernate-JIRA] Created: (HHH-5234) 2-phase load components

by Steve Ebersole (JIRA)

2-phase load components ----------------------- Key: HHH-5234 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5234 Project: Hibernate Core Issue Type: New Feature Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.6 This piece is the crux needed for many of the planned improvements wrt components: # component inheritance (discriminator based) # full key-many-to-one support # 'loaded state' tracking for orphan delete semantics -- 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

14 years, 4 months

1
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2079) Add pre flush event listener holding all the changed entities and the operations on them

by Shay Banon (JIRA)

Add pre flush event listener holding all the changed entities and the operations on them ---------------------------------------------------------------------------------------- Key: HHH-2079 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2079 Project: Hibernate3 Type: New Feature Components: core Versions: 3.2.0.ga Reporter: Shay Banon Is there a chance to add a pre flush event listener. The event listener will have all the entities changes about to be flushed, including the operation about to be performed on them (delete, update, create). This issue relates to HHH-1725 and the collection not processed by flush exception. Maybe there would be a chance to load the lazy collections before the actual flush operation using the mentioned listener. -- 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

14 years, 4 months

4
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2434) No standard way to calculate date intervals in HQL

by Don Smith (JIRA)

No standard way to calculate date intervals in HQL -------------------------------------------------- Key: HHH-2434 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2434 Project: Hibernate3 Type: Improvement Components: core Versions: 3.2.0.ga Environment: All Reporter: Don Smith Priority: Minor Date interval calculation is supported differently on different database platforms. Some allow direct arithmetic on columns, i.e. enddate - startdate. Some require functions, datediff(), timestampdiff(), etc. This causes cross-platform issues. For instance, an application I work on has to figure out the dialect that's in use (out of the four we currently support) and create the HQL string differently for each platform. This is undesirable, since we use Hibernate to enable platform neutrality; our installer asks which database the customer wants to deploy to, and sets the dialect. We'd like our codebase to be free of dialect-specific code. I propose a standard solution for this, either direct date arithmetic, or a function defintion that is ported across dialects. Timestampdiff seems to be a fairly standard function, although DB2 has different syntax than MySQL and Derby. I've seen hints that timestampdiff is part of the ANSI SQL standard, but do not have access to the documents to determine if that is the case. -- 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

14 years, 4 months

6
16
0 / 0

[Hibernate-JIRA] Created: (HHH-3348) loading context

by benjamin Leroux (JIRA)

loading context --------------- Key: HHH-3348 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3348 Project: Hibernate3 Issue Type: New Feature Affects Versions: 4.x Reporter: benjamin Leroux Priority: Minor this proposal is for creating a loading context into hibernate Let me explain: On an application, we often hesitating between the two major strategies of loading (eager or lazy). But for some reason there has no good choice. In fact, it depends on the context. So we do lazy loading and redefine some method with new request with some "join". In fact, it lead to complexity and decrease managability of the application. So my idea is to allow the definition of a context (like transactional context) where we we can put the loading strategie to adopt. with annotation it could be very easy to define such context. Let see this exemple : Avec les annotations, cela pourrait conduire à une ecriture de ce style : @LoadingStrategie (type=eager from="Car" get={"driver"}) public List<Car> getAllCarForDriving(){ // Some fonctions } @LoadingStrategie (type=eager from="Car" get={"driver","passengers"}) public List<Car> getAllCarForTravelling(){ // Some fonctions } In the method getAllCarForDriving when we call a hql request on car it automaticaly get driver but in the method getAllCarForTravelling passengers and the driver is loaded. -- 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

14 years, 4 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5184) Create a ConnectionAcquisitionMode as corollary to ConnectionReleaseMode

by Steve Ebersole (JIRA)

Create a ConnectionAcquisitionMode as corollary to ConnectionReleaseMode ------------------------------------------------------------------------ Key: HHH-5184 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5184 Project: Hibernate Core Issue Type: Improvement Reporter: Steve Ebersole Fix For: 3.6 Originally ConnectionReleaseMode was added to work around a particular problem of connection "leaking" by JTA containers when used in situations of nested session EJB calls. The connection was not really leaked, but it would appear that way to the JTA resource tracker. The situation was: {code} class EJB1 { public void doSomething() { Session s = getCurrentSession(); ... ejb2.doSomethingElse(); // now use the HIbernate session } } class EJB2 { public void doSomethingElse() { Session s = getCurrentSession(); // Use the session in a way that requires a Connection... } } {code} What happens is that EJB1 obtains a Session reference. Just getting a Hibernate Session does not make it get a Connection; the Session delays getting a Connection until it actually needs one. EJB1 then makes the call into EJB2. Again, EJB2 obtains the same Session reference and does some work, so the Session obtains a Connection. Historically that Connection would be held until the Session closed. However that was problematic in this scenario above; to the JTA container it looks like EJB2.doSomethingElse() is leaking the connection outside the transaction boundary (this was many years ago and AFAIU many of these JTA scoping routines have become more sophisticated). At the time we decided to add the idea of Connection "releasing". However constantly releasing and re-obtaining the Connection can affect performance. Another solution to the problem above is to obtain the Connection up front instead. So initially I see: ConnectionAcquisitionMode.AS_NEEDED ConnectionAcquisitionMode.IMMEDIATELY -- 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

14 years, 4 months

1
5
0 / 0

[Hibernate-JIRA] Created: (HHH-3512) Registration of IdentifierGenerators (short naming)

by Steve Ebersole (JIRA)

Registration of IdentifierGenerators (short naming) --------------------------------------------------- Key: HHH-3512 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3512 Project: Hibernate Core Issue Type: New Feature Components: core, metamodel Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.4, 4.x Another way to look at this is to allow configuration of IdentifierGeneratorFactory. Either allow explicit registration under a short name in config: <identifier-generator name="sequence-style" class="org.hibernate.id.enhanced.SequenceStyleGenerator"/> or via an explicit contract: public interface Registerable { public String getRegistrationName(); } public class SequenceStyleGenerator implements IdentifierGenerator, Registerable { ... public String getRegistrationName() { return "sequence-style"; } } The second, while certainly more verbose, can be used applied to other situations where we want to allow registration moving forward (types, property-accessor, etc). -- 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

14 years, 4 months

2
8
0 / 0

[Hibernate-JIRA] Created: (HHH-2764) EntityType.deepCopy needs to copy for EntityType.DOM4J

by Alan Krueger (JIRA)

EntityType.deepCopy needs to copy for EntityType.DOM4J ------------------------------------------------------ Key: HHH-2764 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2764 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.2 Environment: Hibernate 3.2.2 Reporter: Alan Krueger Using DOM4J with a set of composite-elements that contains a many-to-one. When loading this from the database, the many-to-one piece of the composite-element is disappearing from the XML. I can see the collection being built and the properties on the elements of the collection being set, but the many-to-one property disappears after that. Investigating this, it looks like when PersistentElementHolder.getSnapshot is called and a deepCopy is performed, the EntityType.deepCopy method returns the value to be copied rather than copying it. This interacts poorly with the DOM4J tree, since each Element can only have a single Element parent. When the properties are set on this, a detach is performed that yanks the original element out of its parent. -- 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

14 years, 4 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-4739) InheritanceType.SINGLE_TABLE don't work with Postgresql 8.4.1 and postgresql-8.4-701.jdbc3.jar

by Robert Anderson Nogueira de Oliveira (JIRA)

InheritanceType.SINGLE_TABLE don't work with Postgresql 8.4.1 and postgresql-8.4-701.jdbc3.jar ---------------------------------------------------------------------------------------------- Key: HHH-4739 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4739 Project: Hibernate Core Issue Type: Bug Components: annotations, core, entity-manager, testsuite Affects Versions: 3.3.1 Environment: JBoss Seam 2.2.0-GA, PostgreSQL 8.4.1, postgresql-8.4-701.jdbc3.jar Reporter: Robert Anderson Nogueira de Oliveira Attachments: main-classes.zip @Entity public class FenomenoMetadado implements Serializable { /** * */ private static final long serialVersionUID = 1L; @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Integer id; @NotNull private String nome; private String descricao; @OneToMany(fetch = FetchType.LAZY, cascade = CascadeType.ALL, mappedBy = "fenomenoMetadado") private List<AtributoMetadado> atributosMetadado; /* Getters and Setters */ } @Entity @Inheritance(strategy=InheritanceType.SINGLE_TABLE) public abstract class AtributoMetadado implements Serializable { /** * */ private static final long serialVersionUID = 1L; @Id @GeneratedValue(strategy=GenerationType.IDENTITY) private Integer id; @NotNull private String nome; @NotNull private String label; @NotNull private Boolean requerido; @ManyToOne @JoinColumn(name="fenomenometadado_id", nullable = false) private FenomenoMetadado fenomenoMetadado; /* Getters and Setters */ } @Entity public class StringMetaDado extends AtributoMetadado { /** * */ private static final long serialVersionUID = 1L; } TestNG: public class FenomenoMetadadoTests extends SeamTest { @Test public void testarCriarRemover() throws Exception { final FenomenoMetadado instalacaoMetaDado = new FenomenoMetadado(); instalacaoMetaDado.setNome("Instalações"); instalacaoMetaDado.setDescricao("Instalações de Petróleo e Gás"); List<AtributoMetadado> atributos = new ArrayList<AtributoMetadado>(); StringMetaDado att1 = new StringMetaDado(); att1.setLabel("Nome"); att1.setNome("nome"); att1.setRequerido(true); att1.setFenomenoMetadado(instalacaoMetaDado); atributos.add(att1); instalacaoMetaDado.setAtributosMetadado(atributos); new FacesRequest() { protected void invokeApplication() { EntityManager em = (EntityManager) getValue("#{entityManager}"); try { em.persist(instalacaoMetaDado); } catch (Exception e) { e.printStackTrace(); fail("Hibernate Bug with postgresql-8.4-701.jdbc3.jar"); } } }.run(); } Stacktrace: Hibernate: insert into FenomenoMetadado (descricao, nome) values (?, ?) Hibernate: insert into AtributoMetadado (fenomenometadado_id, label, nome, requerido, DTYPE) values (?, ?, ?, ?, 'StringMetaDado') ERROR [org.hibernate.util.JDBCExceptionReporter] Valor inválido para tipo int : StringMetaDado javax.persistence.PersistenceException: org.hibernate.exception.DataException: could not insert: [org.domain.geoinfra.entity.StringMetaDado] at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:614) at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:226) at org.jboss.seam.persistence.EntityManagerProxy.persist(EntityManagerProxy.java:137) at org.hibernate.search.jpa.impl.FullTextEntityManagerImpl.persist(FullTextEntityManagerImpl.java:93) at org.jboss.seam.persistence.EntityManagerProxy.persist(EntityManagerProxy.java:137) at tests.FenomenoMetadadoTests$2.invokeApplication(FenomenoMetadadoTests.java:74) at org.jboss.seam.mock.AbstractSeamTest$Request.invokeApplicationPhase(AbstractSeamTest.java:646) at org.jboss.seam.mock.AbstractSeamTest$Request.emulateJsfLifecycle(AbstractSeamTest.java:595) at org.jboss.seam.mock.AbstractSeamTest$Request.access$100(AbstractSeamTest.java:177) at org.jboss.seam.mock.AbstractSeamTest$Request$2.doFilter(AbstractSeamTest.java:497) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83) at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178) at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290) at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368) at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495) at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158) at org.jboss.seam.mock.AbstractSeamTest$Request.run(AbstractSeamTest.java:491) at tests.FenomenoMetadadoTests.testarCriarRemover(FenomenoMetadadoTests.java:82) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:644) at org.testng.internal.Invoker.invokeMethod(Invoker.java:546) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:700) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1002) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:137) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:121) at org.testng.TestRunner.runWorkers(TestRunner.java:908) at org.testng.TestRunner.privateRun(TestRunner.java:617) at org.testng.TestRunner.run(TestRunner.java:498) at org.testng.SuiteRunner.runTest(SuiteRunner.java:329) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:324) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:296) at org.testng.SuiteRunner.run(SuiteRunner.java:201) at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:915) at org.testng.TestNG.runSuitesLocally(TestNG.java:879) at org.testng.TestNG.run(TestNG.java:787) at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:75) at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:127) Caused by: org.hibernate.exception.DataException: could not insert: [org.domain.geoinfra.entity.StringMetaDado] at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:100) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66) at org.hibernate.id.insert.AbstractReturningDelegate.performInsert(AbstractReturningDelegate.java:64) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2186) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2666) at org.hibernate.action.EntityIdentityInsertAction.execute(EntityIdentityInsertAction.java:71) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279) at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:321) at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204) at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:130) at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49) at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154) at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110) at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:636) at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:628) at org.hibernate.engine.EJB3CascadingAction$1.cascade(EJB3CascadingAction.java:28) at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:291) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:239) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192) at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:319) at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:265) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:242) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192) at org.hibernate.engine.Cascade.cascade(Cascade.java:153) at org.hibernate.event.def.AbstractSaveEventListener.cascadeAfterSave(AbstractSaveEventListener.java:479) at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:357) at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204) at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:130) at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49) at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154) at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110) at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:61) at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:645) at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:619) at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:623) at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:220) ... 50 more Caused by: org.postgresql.util.PSQLException: Valor inválido para tipo int : StringMetaDado at org.postgresql.jdbc2.AbstractJdbc2ResultSet.toInt(AbstractJdbc2ResultSet.java:2759) at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getInt(AbstractJdbc2ResultSet.java:2003) at org.jboss.resource.adapter.jdbc.WrappedResultSet.getInt(WrappedResultSet.java:673) at org.hibernate.id.IdentifierGeneratorFactory.get(IdentifierGeneratorFactory.java:107) at org.hibernate.id.IdentifierGeneratorFactory.getGeneratedIdentity(IdentifierGeneratorFactory.java:92) at org.hibernate.id.IdentityGenerator$GetGeneratedKeysDelegate.executeAndExtract(IdentityGenerator.java:98) at org.hibernate.id.insert.AbstractReturningDelegate.performInsert(AbstractReturningDelegate.java:57) ... 83 more If I use the jdbc driver postgresql-8.3-605.jdbc3.jar it works fine. -- 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

14 years, 4 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-4450) MapKey with key as entity not working

by shay (JIRA)

MapKey with key as entity not working -------------------------------------- Key: HHH-4450 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4450 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.2 Environment: hibernate annotations 3.4.0 , Hibernate-core 3.3.2 , Postgres 1.8.4 Reporter: shay Priority: Blocker Attachments: testbug.zip when using an entity as key , map is inaccessible(NullPointerException for items) . Its seems that when HashCode is called on the Key , the properties in key have not been populated, which prevents the map from loading properly Test case attached Thank you for your help Shay Matasaro -- 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

14 years, 4 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5235) MultipleHiLoPerTableGenerator infers catalogs and schemas where none should be inferred

by Laird Nelson (JIRA)

MultipleHiLoPerTableGenerator infers catalogs and schemas where none should be inferred --------------------------------------------------------------------------------------- Key: HHH-5235 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5235 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.2 Environment: Hibernate 3.5.2-Final, H2 database version 1.2.134 Reporter: Laird Nelson I have a @TableGenerator annotation and an associated @GeneratedValue like this: @Entity(name = "PostalAddress") @TableGenerator( name = "PostalAddressEntityIDGenerator", table = "JPAGenerators", pkColumnName = "generatorName", pkColumnValue = "PostalAddressEntityIDGenerator", valueColumnName = "generatorValue", allocationSize = 1 ) public class PostalAddressEntity { @GeneratedValue(strategy = GenerationType.TABLE, generator = "PostalAddressEntityIDGenerator") @Id private long id; /* etc. */ } At runtime, the following SQL shows up: select generatorValue from JPAGenerators.JPAGenerators.JPAGenerators where generatorName = 'PostalAddressEntityIDGenerator' for update Note the table name repeated three times as though it is both the catalog, the schema and the table name. It seems that the MultipleHiLoPerTableGenerator, when asked to build its SQL strings for various operations, is told that the schema, the catalog and the table name are all the same. I was expecting that the catalog would default to "", per the TableGenerator documentation, and that the schema would default to whatever was present in orm.xml's persistence-unit-defaults element. I can work around this by explicitly spelling out the schema name in my @TableGenerator annotation, but I don't want to put it there (can't, actually). I can also work around this in a JPA-compliant manner by defining my table generator in my orm.xml file, but I don't want to do that either. -- 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

14 years, 4 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-472) Runtime creation of new shards

by Dobes Vandermeer (JIRA)

Runtime creation of new shards ------------------------------ Key: HSEARCH-472 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-472 Project: Hibernate Search Issue Type: New Feature Components: query Affects Versions: 3.2.0.Beta1 Reporter: Dobes Vandermeer Priority: Minor Hibernate Search's shard support has added the ability to select a shard based on a parameter of the query; however, you must use a fixed number of shards. In order to best support our use case originally reported in http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-470 it would be necessary to add support for dynamically added shards at runtime. Also related: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-251 and http://www.opensubscriber.com/message/hibernate-dev@lists.jboss.org/97703... -- 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

14 years, 4 months

3
28
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-521) Improve performance MassIndexer through Eager fetching

by Marc Schipperheyn (JIRA)

Improve performance MassIndexer through Eager fetching ------------------------------------------------------ Key: HSEARCH-521 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-521 Project: Hibernate Search Issue Type: Improvement Components: engine Affects Versions: 3.2.0.CR1 Reporter: Marc Schipperheyn Priority: Minor The MassIndexer fetches all of a certain entity from the database. It then proceeds to index it and the tree of IndexedEmbedded objects is traversed. In doing so, a lot of additional queries get executed. These queries are not really necessary, since we know beforehand that the data is needed for the indexing operation. So it would make sense to eagerly fetch all associations that are marked as indexEmbedded. This way MassIndexer would significantly speed up. -- 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

14 years, 4 months

3
10
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-349) Allow custom Loader in FullTextQueryImpl

by Julien Kronegg (JIRA)

Allow custom Loader in FullTextQueryImpl ---------------------------------------- Key: HSEARCH-349 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-349 Project: Hibernate Search Issue Type: New Feature Components: query Affects Versions: 3.1.0.GA Environment: Hibernate 3.3.1.GA, DB2 Reporter: Julien Kronegg Priority: Minor When doing an native SQL query containing join and other complicated stuff, one can get a List<MyObject> using the following code: List<MyObject> list = entityManager.createNativeQuery("SELECT ...", MyObject.class).getResultList(); The MyObject class is an JPA Entity, but is not connected to a database table: the MyObject instance is reconstructed automatically by mapping the ResultSet column names and the MyObject field names. This object list can be indexed using Hibernate Search (by adding @Indexed and @Field annotations to the MyObject entity). When doing an Hibernate Search query, the FullTextQueryImpl.list() method uses a Loader which try to load the MyObject entities from the database by a query such as "SELECT ... FROM MYOBJECT where id in (?,?,?,..)" (where the list of "?" is the list of identifiers returned by Lucene). Here, we have a problem: the MYOBJECT table does not exist and obviously an exception is raised. The desired result would be for example to look into the initial List<MyObject> "list" instead of asking to the database. This functionnality could be done very simply by adding a "Loader customLoader" field (with its public getter/setter) in the org.hibernate.search.query.FullTextQueryImpl class and by modifying the getLoader() method such as: private Loader getLoader(Session session, SessionFactoryImplementor sessionFactoryImplementor) { if (customLoader!=null) { customLoader.init(session, sessionFactoryImplementor); return customLoader; } ... } After this modification, the programmer can design its own Loader which implements whatever loading strategy. For the example above, the Loader.load(EntityInfo[]) method may looks for each EntityInfo.id in the initially obtained List<MyObject> "list". There is a workaround: copy the full source code of FullTextQueryImpl and add the described modifications. -- 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

14 years, 4 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-431) More details in documentation about MassIndexer

by Sanne Grinovero (JIRA)

More details in documentation about MassIndexer ----------------------------------------------- Key: HSEARCH-431 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-431 Project: Hibernate Search Issue Type: Task Components: documentation Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 3.2.0.Beta3 Add the new diagram Emmanuel has drawn with explanations about the different stages and pipelines of MassIndexer. -- 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

14 years, 4 months

3
10
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-152) Consider using SnapshotDeletionPolicy for hot backup instead of the old locking scheme

by Emmanuel Bernard (JIRA)

Consider using SnapshotDeletionPolicy for hot backup instead of the old locking scheme -------------------------------------------------------------------------------------- Key: HSEARCH-152 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-152 Project: Hibernate Search Issue Type: New Feature Components: directory provider Reporter: Emmanuel Bernard Not sure it's really interesting in our environment though -- 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

14 years, 4 months

2
11
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-376) Delegate search to remote nodes and aggregate

by Emmanuel Bernard (JIRA)

Delegate search to remote nodes and aggregate --------------------------------------------- Key: HSEARCH-376 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-376 Project: Hibernate Search Issue Type: New Feature Reporter: Emmanuel Bernard This would require to - discover the participating nodes - replace the IndexReaders with Searchable (for some valid reasons I chose not to initially) - use a ParallelMultiIndexSearcher - expose IndexSearcher remotely. will be be useful for infinispan -- 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

14 years, 4 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-336) Create a DirectoryProvider for InstantiatedIndex

by Sanne Grinovero (JIRA)

Create a DirectoryProvider for InstantiatedIndex ------------------------------------------------ Key: HSEARCH-336 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-336 Project: Hibernate Search Issue Type: New Feature Components: directory provider Reporter: Sanne Grinovero Assignee: Sanne Grinovero have an option to copy startup data from at startup (like clone a FSDirectory) ? -- 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

14 years, 4 months

3
12
0 / 0

[Hibernate-JIRA] Created: (HHH-4601) implement orphanRemoval for *ToMany and OneToOne

by Emmanuel Bernard (JIRA)

implement orphanRemoval for *ToMany and OneToOne ------------------------------------------------ Key: HHH-4601 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4601 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

14 years, 4 months

5
9
0 / 0

[Hibernate-JIRA] Created: (HHH-2459) Problem with <parent> for 2+ levels of components

by Kevin Bragh (JIRA)

Problem with <parent> for 2+ levels of components ------------------------------------------------- Key: HHH-2459 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2459 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.2 Environment: Hibernate 3.2.2, Tested on PostgreSQL and HSQL Reporter: Kevin Bragh Attachments: test.zip I have tested several scenarios similar to the above, and I have searched and posted to the forum with no response. I have attached the faulty code to the thread. I have a main class (A) with 3 components recusively included as follows: A -> B -> C <-> D In the case above, D has a <parent> property to C. While loading an instance of A, it seems that D.setC(...) is called with the value of the main class A, and not of parent C. I don't know if this is a bug, or if parent is not recusively supported. Any help is appreciated. Thks, K. NB: I have tried many different examples (with list and composite-element, etc.) and they all fail with 2+ levels of recursion. Log ----- 2007-03-01 14:53:07,843 DEBUG [org.hibernate.impl.SessionImpl] - <opened session at timestamp: 4803613441277952> 2007-03-01 14:53:07,843 DEBUG [org.hibernate.transaction.JDBCTransaction] - <begin> 2007-03-01 14:53:07,843 DEBUG [org.hibernate.jdbc.ConnectionManager] - <opening JDBC connection> 2007-03-01 14:53:07,843 DEBUG [org.hibernate.connection.DriverManagerConnectionProvider] - <total checked-out connections: 0> 2007-03-01 14:53:07,843 DEBUG [org.hibernate.connection.DriverManagerConnectionProvider] - <using pooled JDBC connection, pool size: 0> 2007-03-01 14:53:07,843 DEBUG [org.hibernate.transaction.JDBCTransaction] - <current autocommit status: false> 2007-03-01 14:53:07,843 DEBUG [org.hibernate.jdbc.JDBCContext] - <after transaction begin> 2007-03-01 14:53:07,843 DEBUG [org.hibernate.event.def.DefaultSaveOrUpdateEventListener] - <saving transient instance> 2007-03-01 14:53:07,843 DEBUG [org.hibernate.event.def.AbstractSaveEventListener] - <saving [test.hibernate.recurse.A#<null>]> 2007-03-01 14:53:07,843 DEBUG [org.hibernate.event.def.AbstractSaveEventListener] - <executing insertions> 2007-03-01 14:53:07,859 DEBUG [org.hibernate.engine.Versioning] - <using initial version: 0> 2007-03-01 14:53:07,859 DEBUG [org.hibernate.persister.entity.AbstractEntityPersister] - <Inserting entity: test.hibernate.recurse.A (native id)> 2007-03-01 14:53:07,859 DEBUG [org.hibernate.persister.entity.AbstractEntityPersister] - <Version: 0> 2007-03-01 14:53:07,859 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to open PreparedStatement (open PreparedStatements: 0, globally: 0)> 2007-03-01 14:53:07,859 DEBUG [org.hibernate.SQL] - <insert into TEST_A (NO_VERSION, VAL, VAL_B, VAL_C, VAL_D, UID) values (?, ?, ?, ?, ?, null)> Hibernate: insert into TEST_A (NO_VERSION, VAL, VAL_B, VAL_C, VAL_D, UID) values (?, ?, ?, ?, ?, null) 2007-03-01 14:53:07,859 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <preparing statement> 2007-03-01 14:53:07,859 DEBUG [org.hibernate.persister.entity.AbstractEntityPersister] - <Dehydrating entity: [test.hibernate.recurse.A#<null>]> 2007-03-01 14:53:07,859 DEBUG [org.hibernate.type.IntegerType] - <binding '0' to parameter: 1> 2007-03-01 14:53:07,859 DEBUG [org.hibernate.type.IntegerType] - <binding '0' to parameter: 2> 2007-03-01 14:53:07,859 DEBUG [org.hibernate.type.IntegerType] - <binding '0' to parameter: 3> 2007-03-01 14:53:07,859 DEBUG [org.hibernate.type.IntegerType] - <binding '0' to parameter: 4> 2007-03-01 14:53:07,859 DEBUG [org.hibernate.type.IntegerType] - <binding '0' to parameter: 5> 2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to close PreparedStatement (open PreparedStatements: 1, globally: 1)> 2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <closing statement> 2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to open PreparedStatement (open PreparedStatements: 0, globally: 0)> 2007-03-01 14:53:07,875 DEBUG [org.hibernate.SQL] - <call identity()> Hibernate: call identity() 2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <preparing statement> 2007-03-01 14:53:07,875 DEBUG [org.hibernate.id.IdentifierGeneratorFactory] - <Natively generated identity: 1> 2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to close PreparedStatement (open PreparedStatements: 1, globally: 1)> 2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <closing statement> 2007-03-01 14:53:07,875 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <flushing session> 2007-03-01 14:53:07,875 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <processing flush-time cascades> 2007-03-01 14:53:07,875 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <dirty checking collections> 2007-03-01 14:53:07,875 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushing entities and processing referenced collections> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Processing unreferenced collections> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Scheduling collection removes/(re)creates/updates> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushed: 0 insertions, 0 updates, 0 deletions to 1 objects> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.pretty.Printer] - <listing entities:> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.pretty.Printer] - <test.hibernate.recurse.A{val=0, b=component[valB,c]{valB=0, c=component[valC,d]{d=component[valD]{valD=0}, valC=0}}, id=1, version=0}> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <executing flush> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <post flush> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.transaction.JDBCTransaction] - <commit> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.impl.SessionImpl] - <automatically flushing session> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <flushing session> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <processing flush-time cascades> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <dirty checking collections> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushing entities and processing referenced collections> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Processing unreferenced collections> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Scheduling collection removes/(re)creates/updates> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushed: 0 insertions, 0 updates, 0 deletions to 1 objects> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.pretty.Printer] - <listing entities:> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.pretty.Printer] - <test.hibernate.recurse.A{val=0, b=component[valB,c]{valB=0, c=component[valC,d]{d=component[valD]{valD=0}, valC=0}}, id=1, version=0}> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <executing flush> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <post flush> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.JDBCContext] - <before transaction completion> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.impl.SessionImpl] - <before transaction completion> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.transaction.JDBCTransaction] - <committed JDBC Connection> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.JDBCContext] - <after transaction completion> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.ConnectionManager] - <aggressively releasing JDBC connection> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.ConnectionManager] - <closing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.connection.DriverManagerConnectionProvider] - <returning connection to pool, pool size: 1> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.impl.SessionImpl] - <after transaction completion> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.impl.SessionImpl] - <closing session> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.ConnectionManager] - <connection already null in cleanup : no action> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.impl.SessionImpl] - <opened session at timestamp: 4803613441597440> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.transaction.JDBCTransaction] - <begin> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.ConnectionManager] - <opening JDBC connection> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.connection.DriverManagerConnectionProvider] - <total checked-out connections: 0> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.connection.DriverManagerConnectionProvider] - <using pooled JDBC connection, pool size: 0> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.transaction.JDBCTransaction] - <current autocommit status: false> 2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.JDBCContext] - <after transaction begin> 2007-03-01 14:53:07,906 DEBUG [org.hibernate.engine.query.QueryPlanCache] - <unable to locate HQL query plan in cache; generating (from test.hibernate.recurse.A)> 2007-03-01 14:53:07,921 DEBUG [org.hibernate.jdbc.ConnectionManager] - <running Session.finalize()> 2007-03-01 14:53:08,000 DEBUG [org.hibernate.hql.ast.QueryTranslatorImpl] - <parse() - HQL: from test.hibernate.recurse.A> 2007-03-01 14:53:08,015 DEBUG [org.hibernate.hql.ast.AST] - <--- HQL AST --- \-[QUERY] 'query' \-[SELECT_FROM] 'SELECT_FROM' \-[FROM] 'from' \-[RANGE] 'RANGE' \-[DOT] '.' +-[DOT] '.' | +-[DOT] '.' | | +-[IDENT] 'test' | | \-[IDENT] 'hibernate' | \-[IDENT] 'recurse' \-[IDENT] 'A' > 2007-03-01 14:53:08,031 DEBUG [org.hibernate.hql.ast.ErrorCounter] - <throwQueryException() : no errors> 2007-03-01 14:53:08,078 DEBUG [org.hibernate.hql.antlr.HqlSqlBaseWalker] - <select << begin [level=1, statement=select]> 2007-03-01 14:53:08,093 DEBUG [org.hibernate.hql.ast.tree.FromElement] - <FromClause{level=1} : test.hibernate.recurse.A (no alias) -> a0_> 2007-03-01 14:53:08,093 DEBUG [org.hibernate.hql.antlr.HqlSqlBaseWalker] - <select : finishing up [level=1, statement=select]> 2007-03-01 14:53:08,093 DEBUG [org.hibernate.hql.ast.HqlSqlWalker] - <processQuery() : ( SELECT ( FromClause{level=1} TEST_A a0_ ) )> 2007-03-01 14:53:08,109 DEBUG [org.hibernate.hql.ast.HqlSqlWalker] - <Derived SELECT clause created.> 2007-03-01 14:53:08,109 DEBUG [org.hibernate.hql.ast.util.JoinProcessor] - <Using FROM fragment [TEST_A a0_]> 2007-03-01 14:53:08,109 DEBUG [org.hibernate.hql.antlr.HqlSqlBaseWalker] - <select >> end [level=1, statement=select]> 2007-03-01 14:53:08,109 DEBUG [org.hibernate.hql.ast.AST] - <--- SQL AST --- \-[SELECT] QueryNode: 'SELECT' querySpaces (TEST_A) +-[SELECT_CLAUSE] SelectClause: '{derived select clause}' | +-[SELECT_EXPR] SelectExpressionImpl: 'a0_.UID as UID0_' {FromElement{explicit,not a collection join,not a fetch join,fetch non-lazy properties,classAlias=null,role=null,tableName=TEST_A,tableAlias=a0_,origin=null,colums={,className=test.hibernate.recurse.A}}} | \-[SQL_TOKEN] SqlFragment: 'a0_.NO_VERSION as NO2_0_, a0_.VAL as VAL0_, a0_.VAL_B as VAL4_0_, a0_.VAL_C as VAL5_0_, a0_.VAL_D as VAL6_0_' \-[FROM] FromClause: 'from' FromClause{level=1, fromElementCounter=1, fromElements=1, fromElementByClassAlias=[], fromElementByTableAlias=[a0_], fromElementsByPath=[], collectionJoinFromElementsByPath=[], impliedElements=[]} \-[FROM_FRAGMENT] FromElement: 'TEST_A a0_' FromElement{explicit,not a collection join,not a fetch join,fetch non-lazy properties,classAlias=null,role=null,tableName=TEST_A,tableAlias=a0_,origin=null,colums={,className=test.hibernate.recurse.A}} > 2007-03-01 14:53:08,109 DEBUG [org.hibernate.hql.ast.ErrorCounter] - <throwQueryException() : no errors> 2007-03-01 14:53:08,125 DEBUG [org.hibernate.hql.ast.QueryTranslatorImpl] - <HQL: from test.hibernate.recurse.A> 2007-03-01 14:53:08,125 DEBUG [org.hibernate.hql.ast.QueryTranslatorImpl] - <SQL: select a0_.UID as UID0_, a0_.NO_VERSION as NO2_0_, a0_.VAL as VAL0_, a0_.VAL_B as VAL4_0_, a0_.VAL_C as VAL5_0_, a0_.VAL_D as VAL6_0_ from TEST_A a0_> 2007-03-01 14:53:08,125 DEBUG [org.hibernate.hql.ast.ErrorCounter] - <throwQueryException() : no errors> 2007-03-01 14:53:08,140 DEBUG [org.hibernate.engine.query.HQLQueryPlan] - <HQL param location recognition took 0 mills (from test.hibernate.recurse.A)> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.engine.query.QueryPlanCache] - <located HQL query plan in cache (from test.hibernate.recurse.A)> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.engine.query.HQLQueryPlan] - <find: from test.hibernate.recurse.A> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.engine.QueryParameters] - <named parameters: {}> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to open PreparedStatement (open PreparedStatements: 0, globally: 0)> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.SQL] - <select a0_.UID as UID0_, a0_.NO_VERSION as NO2_0_, a0_.VAL as VAL0_, a0_.VAL_B as VAL4_0_, a0_.VAL_C as VAL5_0_, a0_.VAL_D as VAL6_0_ from TEST_A a0_> Hibernate: select a0_.UID as UID0_, a0_.NO_VERSION as NO2_0_, a0_.VAL as VAL0_, a0_.VAL_B as VAL4_0_, a0_.VAL_C as VAL5_0_, a0_.VAL_D as VAL6_0_ from TEST_A a0_ 2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <preparing statement> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to open ResultSet (open ResultSets: 0, globally: 0)> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <processing result set> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <result set row: 0> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.LongType] - <returning '1' as column: UID0_> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <result row: EntityKey[test.hibernate.recurse.A#1]> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <Initializing object from ResultSet: [test.hibernate.recurse.A#1]> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.persister.entity.AbstractEntityPersister] - <Hydrating entity: [test.hibernate.recurse.A#1]> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.IntegerType] - <returning '0' as column: NO2_0_> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.IntegerType] - <returning '0' as column: VAL0_> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.IntegerType] - <returning '0' as column: VAL4_0_> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.IntegerType] - <returning '0' as column: VAL5_0_> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.IntegerType] - <returning '0' as column: VAL6_0_> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.engine.TwoPhaseLoad] - <Version: 0> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <done processing result set (1 rows)> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to close ResultSet (open ResultSets: 1, globally: 1)> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to close PreparedStatement (open PreparedStatements: 1, globally: 1)> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <closing statement> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <total objects hydrated: 1> 2007-03-01 14:53:08,156 DEBUG [org.hibernate.engine.TwoPhaseLoad] - <resolving associations for [test.hibernate.recurse.A#1]> 2007-03-01 14:53:08,156 ERROR [org.hibernate.property.BasicPropertyAccessor] - <IllegalArgumentException in class: test.hibernate.recurse.D, setter method of property: c> 2007-03-01 14:53:08,156 ERROR [org.hibernate.property.BasicPropertyAccessor] - <expected type: test.hibernate.recurse.C, actual value: test.hibernate.recurse.A> Exception stack trace ----------------------------- Exception in thread "main" org.hibernate.PropertyAccessException: IllegalArgumentException occurred while calling setter of test.hibernate.recurse.D.c at org.hibernate.property.BasicPropertyAccessor$BasicSetter.set(BasicPropertyAccessor.java:104) at org.hibernate.tuple.PojoComponentTuplizer.setParent(PojoComponentTuplizer.java:132) at org.hibernate.type.ComponentType.instantiate(ComponentType.java:438) at org.hibernate.type.ComponentType.resolve(ComponentType.java:524) at org.hibernate.type.ComponentType.resolve(ComponentType.java:528) at org.hibernate.type.ComponentType.resolve(ComponentType.java:528) at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:113) at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:842) at org.hibernate.loader.Loader.doQuery(Loader.java:717) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:223) at org.hibernate.loader.Loader.doList(Loader.java:2147) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2026) at org.hibernate.loader.Loader.list(Loader.java:2021) at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:369) at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:298) at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:137) at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1014) at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79) at test.hibernate.recurse.Main.main(Main.java:67) Caused by: java.lang.IllegalArgumentException: argument type mismatch at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.hibernate.property.BasicPropertyAccessor$BasicSetter.set(BasicPropertyAccessor.java:42) ... 18 more -- 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

14 years, 4 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-183) @IndexedEmbedded(prefix="") should either be forbidden or fixed with duplicate ID fields

by Stephane Epardaud (JIRA)

@IndexedEmbedded(prefix="") should either be forbidden or fixed with duplicate ID fields ---------------------------------------------------------------------------------------- Key: HSEARCH-183 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-183 Project: Hibernate Search Issue Type: Improvement Components: mapping Affects Versions: 3.0.1.GA Reporter: Stephane Epardaud If all my entities have their ID property named "id" and they use @IndexedEmbedded(prefix="") then there will be several fields named "id" per document. This results in very unfortunate behaviour when indexes are updated because this id is then used by HS to remove Lucene documents, so instead of removing only the one document we are updating, HS removes all documents whose ID have been embedded in the index. We use prefix="" in order to accumulate embedded entities' "text" fields into the root entity so that we can search on any "text" field, embedded or not. This is required because there seems to be no support for a term wildcard such as "*.text:foo" which would search on any term ending by ".text" for the string "foo". Either prefix="" is supported, and this behaviour should be changed, or at the very least trigger a visible warning, or it is not supported and it should be documented and an exception should be thrown. Since it is behaviour I need, I favour supporting it, so I've patched DocumentBuilder to store the ID of the root entity in a special field like _hibernate_class, so that when we update the index only the appropriate entity index document is removed. This works well, but has the side-effect of ignoring the name of the ID as specified in @DocumentId. An alternative would be to still store the root ID is a "special" field, and keep storing the ID under a field name as specified by the user. As long as we only use the "special" ID for index updating all will work well. I can produce both patches and documentation if you agree (and choose). -- 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

14 years, 4 months

3
5
0 / 0

[Hibernate-JIRA] Created: (HHH-4108) Invalid result in native query

by Oleksandr Fedorenko (JIRA)

Invalid result in native query ------------------------------ Key: HHH-4108 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4108 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.3.2 Environment: 3.3.2, MySQL 5.1 Reporter: Oleksandr Fedorenko Priority: Critical We have the native query executed with entity manager, example : Query query = entityManager.createNativeQuery(sqlString); List result = query.getResultList(); The returned result is an array of objects that has projection values. When table column has type CHAR(N) , the result value is always instance of java.lang.Character and here we have only first character of database field and the rest characters are lost. It is supposed to have result of java.lang.String class here. When the column is altered to VARCHAR(N), the result is java.lang.String. -- 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

14 years, 5 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3684) Sybase - Setting FetchMode.JOIN fails if there are 3 or more joins and at least one join involves a union

by Gail Badner (JIRA)

Sybase - Setting FetchMode.JOIN fails if there are 3 or more joins and at least one join involves a union --------------------------------------------------------------------------------------------------------- Key: HHH-3684 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3684 Project: Hibernate Core Issue Type: Bug Components: core Reporter: Gail Badner Assignee: Gail Badner This is reproduced by UnionSubclassTest.testUnionSubclassFetchMode().. This may be due to a bug in Sybase. A similar problem is discussed here: http://www.forumtopics.com/busobj/viewtopic.php?p=442226&sid=40bd96248c52... For the unit test mentioned above, changing: select ... from ( select ... from humans union select ... from employees ) this_ inner join locations location2_ on this_.location=location2_.id left outer join ( select ... from employees union select ... from humans union select ... from aliens ) beings3_ on location2_.id=beings3_.location : to: select ... from ( select ... from humans union select ... from employees ) this_ inner join (locations location2_ left outer join ( select ... from employees union select ... from humans union select ... from aliens ) beings3_ on location2_.id=beings3_.location) : on this_.location=location2_.id fixes the problem. This changer is similar to what is documented for a "right-nested outer join" at http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc32300.150.... -- 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

14 years, 5 months

3
11
0 / 0

[Hibernate-JIRA] Created: (HHH-5086) "ambiguous column" SQL errors in Hibernate 3.5.0 Final

by dnalos (JIRA)

"ambiguous column" SQL errors in Hibernate 3.5.0 Final ------------------------------------------------------ Key: HHH-5086 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5086 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.0-Final Environment: Java JDK 1.6.0_19 Hibernate Core 3.5.0 Final hibernate-jpa-2.0-api-1.0.0.Final.jar mysql-connector-java-5.1.10-bin.jar Reporter: dnalos Attachments: HibernateAmbiguousTest.zip After update Hibernate Core to 3.5, we get some Exception like this: Column '_value' in field list is ambiguous (JDBCExceptionReporter.java:101) We create a testcase for you, and the Exception from the testcase: ERROR 15:39:28 0 Column '_value' in field list is ambiguous (JDBCExceptionReporter.java:101) org.hibernate.exception.ConstraintViolationException: could not load an entity: [Invoice#401] at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:96) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66) at org.hibernate.loader.Loader.loadEntity(Loader.java:1937) at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:86) at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:76) at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3270) at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:496) at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:477) at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:227) at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:285) at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:152) at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:1080) at org.hibernate.impl.SessionImpl.get(SessionImpl.java:997) at org.hibernate.impl.SessionImpl.get(SessionImpl.java:990) at HibernateAmbiguousTest.testAmbiguous(HibernateAmbiguousTest.java:55) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Column '_value' in field list is ambiguous at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at com.mysql.jdbc.Util.handleNewInstance(Util.java:406) at com.mysql.jdbc.Util.getInstance(Util.java:381) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1015) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3558) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3490) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1959) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2109) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2648) at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2077) at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2228) at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeQuery(NewProxyPreparedStatement.java:76) at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:208) at org.hibernate.loader.Loader.getResultSet(Loader.java:1849) at org.hibernate.loader.Loader.doQuery(Loader.java:718) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:270) at org.hibernate.loader.Loader.loadEntity(Loader.java:1933) ... 34 more -- 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

14 years, 5 months

3
10
0 / 0

[Hibernate-JIRA] Created: (HHH-5206) mapping TextType with outer join on oracle causes "Stream has already been closed" error

by Strong Liu (JIRA)

mapping TextType with outer join on oracle causes "Stream has already been closed" error ---------------------------------------------------------------------------------------- Key: HHH-5206 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5206 Project: Hibernate Core Issue Type: Bug Components: build Affects Versions: 3.5.1, 3.5.0-Final Reporter: Strong Liu Assignee: Gail Badner org.hibernate.test.onetoone.formula.OneToOneFormulaTest.testOneToOneFormula() fails on oracle {quote} http://www.jroller.com/agrebnev/entry/hibernate_dbms_portability_tips_tricks Instead BLOB I use "long raw". It is a VARBINARY hibernate type. Here I faced with another Oracle problem "java.sql.SQLException: Stream has already been closed" accessing long raw. The problem is that "The Oracle JDBC driver automatically closes any pending inputstreams whenever another database access is made". It means you should get binary data from result set before all other types. In terms of Hibernate the mapping of binary field should be last. And please keep in your mind that you should disable outer join fetching with class which contains this field. {quote} -- 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

14 years, 5 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-461) Improve support for all language specific snowball Analyzers in Lucene/contrib

by Sanne Grinovero (JIRA)

Improve support for all language specific snowball Analyzers in Lucene/contrib ------------------------------------------------------------------------------ Key: HSEARCH-461 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-461 Project: Hibernate Search Issue Type: Improvement Reporter: Sanne Grinovero Fix For: 3.3.0 For Lucene 3.1 Robert Muir did a great job of standardazing and cleaning Analyzers in contrib with many languages support (wrapping snowball analyzers); I'd like to look into having some helper in Hibernate Search in setting them up all to be available as analyzers and couple to entities in some clever way. -- 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

14 years, 5 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-56) Updating a collection does not reindex

by Emmanuel Bernard (JIRA)

Updating a collection does not reindex -------------------------------------- Key: HSEARCH-56 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-56 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.0.0.beta1 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

14 years, 5 months

4
8
0 / 0

[Hibernate-JIRA] Created: (HHH-3220) Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions

by Dan Bisalputra (JIRA)

Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions ----------------------------------------------------------------------------------------------------------------------------------- Key: HHH-3220 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3220 Project: Hibernate3 Issue Type: Patch Components: core Affects Versions: 3.2.6 Environment: Hibernate 3.2.6, Apache Derby on Mac OSX & PC Reporter: Dan Bisalputra Priority: Minor When performing a query in a stateless session, the query loads objects in a two-phase process in which a temporary persistence context is populated with empty objects in the first phase, then the objects' member data are read from the database in the second phase. If one of the objects contains an association or a collection, it performs a recursive call to the session's get() method. The get() method clears the temporary persistence context, so if the parent object contains any other associations to be read in the second phase, Hibernate throws an assertion because they are not found in the persistence context. This patch solves the problem by only clearing the persistence context when the recursion ends. It passes all the unit tests for our application, but I have not tested it with any of the Hibernate unit tests. -- 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

14 years, 5 months

8
17
0 / 0

[Hibernate-JIRA] Created: (ANN-720) cant bind a child using mappedby relating to a parent attribute(polymorphism)

by Nino Martinez (JIRA)

cant bind a child using mappedby relating to a parent attribute(polymorphism) ----------------------------------------------------------------------------- Key: ANN-720 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-720 Project: Hibernate Annotations Issue Type: Bug Components: binder Affects Versions: 3.3.1.GA Environment: osx 10.4, java 1.5 Reporter: Nino Martinez Attachments: JPA101.zip This is pseudo class hieracy @Entity @Inheritance(strategy = InheritanceType.JOINED) Mammal { @ManyToOne Person owner; } @Entity Cat extends Mammal Person{ @Cascade(org.hibernate.annotations.CascadeType.DELETE_ORPHAN) @OneToMany(cascade = { CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REMOVE }, mappedBy = "owner") private List<Cat> cats = new ArrayList<Cat>(); } it gives the error mission property: javax.persistence.PersistenceException: org.hibernate.AnnotationException: mappedBy reference an unknown target entity property: Cat.owner in Person.cats This is the related thread on hibernate forum: http://forum.hibernate.org/viewtopic.php?p=2380570#2380570 I can confirm that the same example does work when using OpenJPA as a provider. Please see attached project for reference. Please do not hesitate me if you have questions. -- 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

14 years, 5 months

7
13
0 / 0

[Hibernate-JIRA] Created: (HHH-3637) Union in where doesn't works for Sybase, need to evict test case

by Juraci Paixao Krohling (JIRA)

Union in where doesn't works for Sybase, need to evict test case ---------------------------------------------------------------- Key: HHH-3637 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3637 Project: Hibernate Core Issue Type: Improvement Components: testsuite Environment: Sybase ASE 15.0.2 Reporter: Juraci Paixao Krohling Assignee: Juraci Paixao Krohling It seems that Sybase doesn't supports UNION inside WHERE clauses, causing the test DynamicFilterTest#testSqlSyntaxOfFiltersWithUnions to fail. The scenario for this test case is not described in the documentation, but I would expect it to work: http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.... The query is: select category0_.CAT_ID as CAT1_6_, category0_.name as name6_, category0_.eff_start_dt as eff3_6_, category0_.eff_end_dt as eff4_6_ from CATEGORY category0_ where 'abc' in ( select d.reg from department d where ( d.dept_id=123 ) union select p.name from sales_person p ) If executed only the queries from inside the where clause (the two selects with union), it works as expected. Also, if removed the union and one of the queries inside the where, it works as expected. So, the problem happens only when using union inside a where clause. For now, I'd suggest to evict this test for Sybase. -- 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

14 years, 5 months

5
10
0 / 0

[Hibernate-JIRA] Created: (HHH-2447) Connection leak if logAndClearWarnings throws

by Jeppe N. Madsen (JIRA)

Connection leak if logAndClearWarnings throws ---------------------------------------------- Key: HHH-2447 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2447 Project: Hibernate3 Type: Bug Components: core Versions: 3.1.3, 3.2.2 Environment: Database product name : DB2/NT Database product version : SQL08025 JDBC driver name : IBM DB2 JDBC Universal Driver Architecture Hibernate 3.1.3 (seems to exist in 3.2.2 as well) JDBC driver version : 2.9.31 Reporter: Jeppe N. Madsen Priority: Minor In ConnectionManager.closeConnection, logAndClearWarnings is called before connection.close() is called. If this call throws an exception, the connection is never closed. We have observed that DB2 sometimes throws an Error because the SQLWarning chain is wrong: [14-02-07 11:36:30:889 CET] 10b0b533 WebGroup E SRVE0026E: [Servlet Error]-[SQLWarning chain holds value that is not a SQLWarning]: java.lang.Error: SQLWarning chain holds value that is not a SQLWarning at java.sql.SQLWarning.getNextWarning(SQLWarning.java:109) at org.hibernate.util.JDBCExceptionReporter.logWarnings(JDBCExceptionReporter.java:50) at org.hibernate.util.JDBCExceptionReporter.logWarnings(JDBCExceptionReporter.java:33) at org.hibernate.util.JDBCExceptionReporter.logAndClearWarnings(JDBCExceptionReporter.java:22) at org.hibernate.jdbc.ConnectionManager.closeConnection(ConnectionManager.java:443) at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:379) at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:318) at org.hibernate.impl.SessionImpl.close(SessionImpl.java:293) -- 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

14 years, 5 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HV-318) Hibernate Validator doesn't compiles in OpenJDK 6

by Juraci Paixao Krohling (JIRA)

Hibernate Validator doesn't compiles in OpenJDK 6 ------------------------------------------------- Key: HV-318 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-318 Project: Hibernate Validator Issue Type: Bug Components: build Environment: RHEL5, OpenJDK6 Reporter: Juraci Paixao Krohling Assignee: Hardy Ferentschik /qa/hudson_ws/workspace/hibernate-validator-trunk/jdk/openjdk-local/label/RHEL5_any/trunk/hibernate-validator/src/test/java/org/hibernate/validator/util/TestUtil.java:[66,30] incompatible types; inferred type argument(s) java.lang.Object do not conform to bounds of type variable(s) T found : <T>javax.validation.bootstrap.ProviderSpecificBootstrap<T> required: java.lang.Object -- 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

14 years, 5 months

3
12
0 / 0

[Hibernate-JIRA] Created: (HHH-4015) one-to-one: foreign key: save Problem

by Sandeep Vaid (JIRA)

one-to-one: foreign key: save Problem ------------------------------------- Key: HHH-4015 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4015 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.2.6 Reporter: Sandeep Vaid Priority: Critical I have one-to-one relationship between class A and class B <class name="A" table="TEMPA" > <id name="aaId" type="string" column="AID" length="10"> <generator class="assigned"></generator> </id> <one-to-one name="b" class="B" constrained="true" outer-join="false" cascade="save-update" /> </class> <class name="B" table="TEMPB" lazy="true"> <id name="baId" type="string" column="BID" length="10"> <generator class="foreign"> <param name="property">a</param> </generator> </id> <one-to-one name="a" class="A" /> </class> Problem 1: When i try to save A, it fires : insert into HBLEARN1.TEMPB (BID) values ('1') and throws error : The insert or update value of the FOREIGN KEY "TEMPB.CC1246876555824" is not equal to any value of the parent key of the parent table. SQLSTATE=23503 Why it is first trying to save 'B' instead of 'A' first ? Problem 2: With this mapping, if i set <property name="hibernate.hbm2ddl.auto">create</property> in hibernate.cfg.xml, It generates TEMPA whose aaId is the foreign key referencing TEMPB. This is also incorrect.. -- 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

14 years, 5 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2075) many-to-one in a properties element causes strange PropertyValueException on flush

by Josh Moore (JIRA)

many-to-one in a properties element causes strange PropertyValueException on flush ---------------------------------------------------------------------------------- Key: HHH-2075 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2075 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.cr4 Environment: HSQLDB Hibernate r10478 Reporter: Josh Moore Attachments: exception.txt, log.txt, properties.zip Full test directory zip (org/hibernate/test/properties) attached. But to summarize, the following test will fail on flush after a simple merge. The exception thrown says that Pixels.sizeC is null -- though it's clearly set in the test case. <code> Image i = new Image(); Pixels p = new Pixels(); p.setSizeC(new Integer(2)); p.setImage(i); // This calls i.getPixels().add(p) // i.setPixels(null); // This makes it work. Session s = openSession(); Transaction t = s.beginTransaction(); // s.merge(i); // This makes it work. p = (Pixels) s.merge(p); // This fails with the exception below. t.commit(); s.close(); </code> The properties element in question is: <code> <properties name="defaultPixelsTag"> <property name="defaultPixels" type="java.lang.Boolean"/> <many-to-one name="image" class="Image" column="image" not-null="true" unique="false" insert="true" update="true" cascade="lock,merge,persist,replicate,refresh,save-update" /> </properties> </code> The reverse side is: <code> <set name="pixels" lazy="true" inverse="true" cascade="lock,merge,persist,replicate,refresh,save-update"> <key column="image" not-null="false"/> <one-to-many class="Pixels"/> </set> </code> -- 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

14 years, 5 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3102) Cascading ManyToOne collections do not eagerly set identifiers on saveOrUpdate()

by Paul Cowan (JIRA)

Cascading ManyToOne collections do not eagerly set identifiers on saveOrUpdate() -------------------------------------------------------------------------------- Key: HHH-3102 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3102 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.4.sp1 Reporter: Paul Cowan Priority: Minor Attachments: HibernateKeyPoolTest.java Hi all, Not 100% sure if you'd call this a 'bug' as I'm not sure if the correct behaviour is actually specified anywhere. It's certainly oddly inconsistent though. Please find attached a standalone test case (requires HSQLDB on the classpath; amend setUp() if you need to use something else) which models a parent-child mapping between 'Mouth' (1) and 'Teeth' (many). The Mouth -> Teeth relationship is bidirectional, with CascadeType.ALL on the single-valued end. Both Mouth and Tooth use a @GenericGenerator, which simply allocates integers from a static keypool. A mouth with one tooth is created, saveOrUpdate()d, session is flushed, a new tooth is added, mouth is saveOrUpdate()d again, and session is again flushed. The debug output is as follows: *** After creation Mouth (id=null) has teeth [canine(id=null)] *** Save Mouth (id=1) has teeth [canine(id=2)] *** Flush Hibernate: insert into Mouth (id) values (?) Hibernate: insert into Tooth (mouthId, name, id) values (?, ?, ?) Mouth (id=1) has teeth [canine(id=2)] *** Add new Mouth (id=1) has teeth [canine(id=2), molar(id=null)] *** Save again Mouth (id=1) has teeth [canine(id=2), molar(id=null)] *** Flush again Hibernate: insert into Tooth (mouthId, name, id) values (?, ?, ?) Mouth (id=1) has teeth [canine(id=2), molar(id=3)] As you can see, when initially created the IDs for the mouth and tooth are both null (obviously correct). The saveOrUpdate() on the Mouth object then generates identifier values, even though no DB write has been done yet (the .flush()). So far, so good. However, when a NEW transient Tooth instance ("molar") is added to the Mouth, and saveOrUpdate() is called once more, the id generator is not invoked, UNTIL such time as the session is flushed. While I guess it's fine for an object in the 'persistent' state not to actually have an identifier until flush-time (e.g. when using DB-side IDENTITY-type generation), it just seems inconsistent that with a @GenericGenerator the behaviour would vary depending on whether the PARENT object was already persistent or not. There are some obvious workarounds (e.g. flush the session upon saving, or save the child entity first independently) but I thought I'd clarify if this behaviour is by design or not and suggest that this be made consistent. -- 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

14 years, 5 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2166) Long "in" lists in queries results in a Java stack overflow exception.

by Philip R. "Pib" Burns (JIRA)

Long "in" lists in queries results in a Java stack overflow exception. ---------------------------------------------------------------------- Key: HHH-2166 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2166 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.ga Environment: Hibernate 3.2.0.cr3 through 3.2.0.ga (at least). Any standard deployment of Sun's JVM on Windows, Linux, or Mac OS X (and presumably other platforms like Solaris) Reporter: Philip R. "Pib" Burns Attachments: NodeTraverser.java With Hibernate 320ga a long "in" list can result in a stack overflow error during the parsing stage. For example, a query element like where x in (:x) or a manually constructed where x in (1,2,3 .....) can generate a stack overflow if the number of elements referenced by x exceeds a number dependent upon the amount of available stack space. For many JVMs, the limit is between 9,000 and 10,000 assuming a relatively empty stack at the point of query execution. We have applications which occasionally use lists several times this size. The stack overflow occurs in org.hibernate.hql.ast.util.NodeTraverser which uses a recursive algorithm to walk a parse tree. Long "in" lists generate a subtree of depth about equal to the number of elements in the list. A sufficiently long list results in a stack overflow when NodeTraverser's internal method visitDepthFirst calls itself too many times. The solution is to replace the recursive tree walking strategy with an iterative one that does not use up stack space. I am attaching the source for a replacement version of . NodeTraverser which implements the iterative tree walking 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

14 years, 5 months

11
41
0 / 0

[Hibernate-JIRA] Created: (HHH-4577) 2L query cache: Low performance of flush and commit due many unnecessary (pre)invalidate calls on UpdateTimestampsCache

by Guenther Demetz (JIRA)

2L query cache: Low performance of flush and commit due many unnecessary (pre)invalidate calls on UpdateTimestampsCache ----------------------------------------------------------------------------------------------------------------------- Key: HHH-4577 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4577 Project: Hibernate Core Issue Type: Improvement Components: caching (L2) Affects Versions: 3.3.2 Environment: Hibernate 3.3.2GA with JBossCache3.2.1.GA as 2L-cache provider SQLServer2008 Reporter: Guenther Demetz Analyzing what our application is mainly doing during flush/commit, we saw that very often the concerning thread is executing in jbosscache stuff (see 2 sample stacktraces below). Analyzing the code we discovered that, if doing 1000 inserts for a determinate entity: -on flush UpdateTimestampsCache.preinvalidate() is called 1000 times for the same space (=table) -on commit UpdateTimestampsCache.invalidate() is called another 1000 times again for the same space (=table) It would be much smarter to collect the interested spaces once per flush and once per commit and then execute the (pre)invalidate once per single space. In the case above it would reduce the calls to one single UpdateTimestampsCache.preinvalidate()call on flush and one single UpdateTimestampsCache.invalidate() on commit. For the commit the enhancement could be following: ActionQueue.java: public void afterTransactionCompletion(boolean success) { int size = executions.size(); final boolean invalidateQueryCache = session.getFactory().getSettings().isQueryCacheEnabled(); Set<Serializable> spaces = invalidateQueryCache ? new HashSet<Serializable>() : null; try { for ( int i = 0; i < size; i++ ) { try { Executable exec = ( Executable ) executions.get( i ); if ( invalidateQueryCache ) { Serializable[] nspaces = exec.getPropertySpaces(); for (int j=0; j < nspaces.length; j++) spaces.add(nspaces[j]); } exec.afterTransactionCompletion( success ); } catch ( CacheException ce ) { log.error( "could not release a cache lock", ce ); // continue loop } catch ( Exception e ) { throw new AssertionFailure( "Exception releasing cache locks", e ); } } } finally { session.getFactory().getUpdateTimestampsCache().invalidate(spaces.toArray(new Serializable[]{})); } executions.clear(); } Stack traces: java.lang.Thread.isInterrupted(Native Method) java.lang.Thread.interrupted(Thread.java:873) java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1134) java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.java:312) java.util.concurrent.LinkedBlockingQueue.put(LinkedBlockingQueue.java:241) org.jboss.cache.RegionImpl.registerEvictionEvent(RegionImpl.java:249) org.jboss.cache.RegionImpl.registerEvictionEvent(RegionImpl.java:234) org.jboss.cache.interceptors.EvictionInterceptor.registerEvictionEventToRegionManager(EvictionInterceptor.java:252) org.jboss.cache.interceptors.EvictionInterceptor.visitPutKeyValueCommand(EvictionInterceptor.java:109) org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) org.jboss.cache.interceptors.MVCCLockingInterceptor.handlePutKeyValueCommand(MVCCLockingInterceptor.java:102) org.jboss.cache.interceptors.base.PrePostProcessingCommandInterceptor.visitPutKeyValueCommand(PrePostProcessingCommandInterceptor.java:88) org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131) org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65) org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) org.jboss.cache.interceptors.TxInterceptor.attachGtxAndPassUpChain(TxInterceptor.java:301) org.jboss.cache.interceptors.TxInterceptor.handleDefault(TxInterceptor.java:283) org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65) org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) org.jboss.cache.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:119) org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178) org.jboss.cache.interceptors.InvocationContextInterceptor.visitPutKeyValueCommand(InvocationContextInterceptor.java:82) org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:287) org.jboss.cache.invocation.CacheInvocationDelegate.put(CacheInvocationDelegate.java:555) org.hibernate.cache.jbc2.util.CacheHelper.put(CacheHelper.java:212) org.hibernate.cache.jbc2.timestamp.TimestampsRegionImpl.put(TimestampsRegionImpl.java:128) org.hibernate.cache.UpdateTimestampsCache.preinvalidate(UpdateTimestampsCache.java:70) - locked org.hibernate.cache.UpdateTimestampsCache@1afcaae org.hibernate.engine.ActionQueue.execute(ActionQueue.java:275) org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263) org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:167) org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321) Stack trace: java.lang.Thread.isInterrupted(Native Method) java.lang.Thread.interrupted(Thread.java:873) java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1158) java.util.concurrent.locks.ReentrantLock.tryLock(ReentrantLock.java:416) org.jboss.cache.util.concurrent.locks.AbstractSharedLockContainer.acquireLock(AbstractSharedLockContainer.java:94) org.jboss.cache.lock.MVCCLockManager.lockAndRecord(MVCCLockManager.java:133) org.jboss.cache.mvcc.MVCCNodeHelper.acquireLock(MVCCNodeHelper.java:157) org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:217) org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:186) org.jboss.cache.interceptors.MVCCLockingInterceptor.handlePutKeyValueCommand(MVCCLockingInterceptor.java:101) org.jboss.cache.interceptors.base.PrePostProcessingCommandInterceptor.visitPutKeyValueCommand(PrePostProcessingCommandInterceptor.java:88) org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131) org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65) org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) org.jboss.cache.interceptors.TxInterceptor.attachGtxAndPassUpChain(TxInterceptor.java:301) org.jboss.cache.interceptors.TxInterceptor.handleDefault(TxInterceptor.java:283) org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65) org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) org.jboss.cache.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:119) org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178) org.jboss.cache.interceptors.InvocationContextInterceptor.visitPutKeyValueCommand(InvocationContextInterceptor.java:82) org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:287) org.jboss.cache.invocation.CacheInvocationDelegate.put(CacheInvocationDelegate.java:555) org.hibernate.cache.jbc2.util.CacheHelper.put(CacheHelper.java:212) org.hibernate.cache.jbc2.timestamp.TimestampsRegionImpl.put(TimestampsRegionImpl.java:128) org.hibernate.cache.UpdateTimestampsCache.invalidate(UpdateTimestampsCache.java:85) - locked org.hibernate.cache.UpdateTimestampsCache@1afcaae org.hibernate.engine.ActionQueue.afterTransactionCompletion(ActionQueue.java:202) -- 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

14 years, 5 months

3
11
0 / 0

[Hibernate-JIRA] Created: (HHH-3850) org.jboss.cache.lock.TimeoutException: failure acquiring lock, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)

by wu bin (JIRA)

org.jboss.cache.lock.TimeoutException: failure acquiring lock, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0) -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-3850 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3850 Project: Hibernate Core Issue Type: Bug Components: caching (L2) Affects Versions: 3.2.6 Environment: linux , oracle 9.2 jboss 4.2.3 Reporter: wu bin we use hibernate and jboss tree cache in jboss 4.2.3 in lnux. we only have 1 node in the cluster. we met this exception: 19:00:58,515 ERROR [TxInterceptor] method invocation failed org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0) at org.jboss.cache.Node.acquire(Node.java:533) at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:410) at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:322) at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:189) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:39) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:568) at org.jboss.cache.interceptors.TxInterceptor.handlePessimisticPrepare(TxInterceptor.java:472) at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:338) at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:145) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183) at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5919) at org.jboss.cache.TreeCache._replicate(TreeCache.java:5196) at sun.reflect.GeneratedMethodAccessor200.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330) at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:281) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:654) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:367) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777) at org.jgroups.JChannel.up(JChannel.java:1091) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:382) at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:398) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158) at org.jgroups.stack.UpHandler.run(Protocol.java:60) Caused by: org.jboss.cache.lock.TimeoutException: write lock for /org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT could not be acquired after 0 ms. Locks: Read lock owners: [] Write lock owner: Thread[http-8443-14,5,jboss] (caller=GlobalTransaction:<16.173.241.57:9242>:119, lock info: <unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)) at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:206) at org.jboss.cache.Node.acquireWriteLock(Node.java:562) at org.jboss.cache.Node.acquire(Node.java:509) ... 31 more 19:00:58,516 ERROR [TxInterceptor] prepare method invocation failed java.lang.RuntimeException: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0) at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:591) at org.jboss.cache.interceptors.TxInterceptor.handlePessimisticPrepare(TxInterceptor.java:472) at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:338) at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:145) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183) at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5919) at org.jboss.cache.TreeCache._replicate(TreeCache.java:5196) at sun.reflect.GeneratedMethodAccessor200.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330) at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:281) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:654) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:367) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777) at org.jgroups.JChannel.up(JChannel.java:1091) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:382) at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:398) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158) at org.jgroups.stack.UpHandler.run(Protocol.java:60) Caused by: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0) at org.jboss.cache.Node.acquire(Node.java:533) at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:410) at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:322) at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:189) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:39) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:568) ... 22 more Caused by: org.jboss.cache.lock.TimeoutException: write lock for /org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT could not be acquired after 0 ms. Locks: Read lock owners: [] Write lock owner: Thread[http-8443-14,5,jboss] (caller=GlobalTransaction:<16.173.241.57:9242>:119, lock info: <unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)) at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:206) at org.jboss.cache.Node.acquireWriteLock(Node.java:562) at org.jboss.cache.Node.acquire(Node.java:509) ... 31 more 19:00:58,516 WARN [TreeCache] replication failure with method_call prepare; id:10; Args: ( arg[0] = GlobalTransaction:<16.173.241.57:9242>:119 ...) exception java.lang.RuntimeException: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0) at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:591) at org.jboss.cache.interceptors.TxInterceptor.handlePessimisticPrepare(TxInterceptor.java:472) at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:338) at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:145) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183) at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5919) at org.jboss.cache.TreeCache._replicate(TreeCache.java:5196) at sun.reflect.GeneratedMethodAccessor200.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330) at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:281) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:654) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:367) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777) at org.jgroups.JChannel.up(JChannel.java:1091) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:382) at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:398) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158) at org.jgroups.stack.UpHandler.run(Protocol.java:60) Caused by: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0) at org.jboss.cache.Node.acquire(Node.java:533) at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:410) at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:322) at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:189) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:39) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:568) ... 22 more Caused by: org.jboss.cache.lock.TimeoutException: write lock for /org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT could not be acquired after 0 ms. Locks: Read lock owners: [] Write lock owner: Thread[http-8443-14,5,jboss] (caller=GlobalTransaction:<16.173.241.57:9242>:119, lock info: <unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)) at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:206) at org.jboss.cache.Node.acquireWriteLock(Node.java:562) at org.jboss.cache.Node.acquire(Node.java:509) ... 31 more -- 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

14 years, 5 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4055) make UpdateTimestampsCache pluggable, like QueryCache

by A. R. (JIRA)

make UpdateTimestampsCache pluggable, like QueryCache ----------------------------------------------------- Key: HHH-4055 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4055 Project: Hibernate Core Issue Type: Improvement Components: caching (L2) Affects Versions: 3.3.2 Environment: all Reporter: A. R. According to https://www.hibernate.org/213.html, one can plug-in one's own query cache using hibernate.cache.query_cache_factory, e.g. to chose a cache strategy that is not based on updateTimestamps. However, Hibernate's SessionFactoryImpl will always create an UpdateTimestampsCache if the Query Cache is enabled, even for custom Query Caches. This UpdateTimestampsCache then is always used in org.hibernate.engine.ActionQueue.execute() and afterTransactionCompletion(). Since the UpdateTimestampsCache is synchronized, this can cause bottlenecks when many threads change things (see http://tech.puredanger.com/2009/07/10/hibernate-query-cache/).. Please make the UpdateTimestampsCache also pluggable, so that one can truly and completely plug one's own Query Cache without using a Update-Timestamps or with a custom UpdateTimestampCache. -- 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

14 years, 5 months

4
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2305) refresh throws exception when database has been altered with a delete

by Markus Heiden (JIRA)

refresh throws exception when database has been altered with a delete --------------------------------------------------------------------- Key: HHH-2305 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2305 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.1 Environment: Hibernate 3.2.1, Oracle 9.2 Reporter: Markus Heiden Attachments: hibernate.zip First I save an entity with a collection of cascading entities in it and flush. Then I delete these cascaded entities with a sql query. When I now do a refresh on the entity an exception is thrown, because the cascaded entities couldn't be found in the database. I expected these entities to be deleted from the (in memory) collection of the entity instead. Test case is attached. Stacktrace of test case: Hibernate: select c0_.id as id2_0_, c0_.c as c2_0_ from C c0_ where c0_.id=? org.hibernate.UnresolvableObjectException: No row with the given identifier exists: [hibernate.refresh.C#30003] at org.hibernate.UnresolvableObjectException.throwIfNull(UnresolvableObjectException.java:42) at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:126) at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:911) at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:894) at org.hibernate.engine.CascadingAction$4.cascade(CascadingAction.java:169) at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:216) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169) at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:296) at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:242) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:219) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169) at org.hibernate.engine.Cascade.cascade(Cascade.java:130) at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:99) at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:911) at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:894) at org.hibernate.engine.CascadingAction$4.cascade(CascadingAction.java:169) at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:216) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169) at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:296) at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:242) at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:219) at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169) at org.hibernate.engine.Cascade.cascade(Cascade.java:130) at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:99) at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:39) at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:902) at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:886) at hibernate.refresh.Test.main(Test.java:46) -- 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

14 years, 5 months

5
5
0 / 0

[Hibernate-JIRA] Created: (HV-274) Write a programmatic mapping API for constraint declarations

by Emmanuel Bernard (JIRA)

Write a programmatic mapping API for constraint declarations ------------------------------------------------------------ Key: HV-274 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-274 Project: Hibernate Validator Issue Type: New Feature Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik -- 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

14 years, 5 months

5
17
0 / 0

[Hibernate-JIRA] Created: (HHH-3360) Custom Oracle Batcher to allow batch updates for versioned data

by Manuel Dominguez Sarmiento (JIRA)

Custom Oracle Batcher to allow batch updates for versioned data --------------------------------------------------------------- Key: HHH-3360 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3360 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.3.0.CR1, 3.2.6, 3.2.5, 3.2.4.sp1, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2.0.ga Environment: Oracle 10g R1, 10g R2, 11g R1 (have not tried previous Oracle versions), 11g R1 drivers (older drivers should also work) Reporter: Manuel Dominguez Sarmiento Priority: Minor Attachments: C3P0OracleBatchingBatcher.java, C3P0OracleBatchingBatcherFactory.java, OracleBatchingBatcher.java, OracleBatchingBatcherFactory.java We have developed a custom Oracle Batcher which allows batching versioned data. The Oracle JDBC driver does not return update counts when using the standard JDBC 2.0 batching mechanism, however the proprietary Oracle batching mechanism allows obtaining the total batch row update count. The update counts are absolutely necessary to detect stale updates. Although it is not exactly the same, the total row update count is actually enough information to be able to batch versioned data and still detect stale updates. We'd like to contribute the attached files. They have a compile time dependency on Oracle JDBC. If this is not acceptable, it could be easily solved by using reflection. Another Batcher is provided for when the Oracle connection is being managed through c3p0 (a common deployment scenario). This has a compile time dependency on c3p0. A few "dirty" tricks were necessary to pull this off without patching other classes. Specifically, it was necessary to override Java private semantics to obtain BasicExpectation.expectedRowCount. This could be easily solved by adding an accessor method to the Expectation interface. There is one issue which we are not completely sure of, however so far we have not found any problems. When the Expectation is NONE, there is no way to check whether the total row count is correct or not, even if other batched updates do have expectations with expected row counts. Our understanding is that actually, since batching requires all statements to be of the same type (since the same PreparedStatement / CallableStatement is being used), then either ALL expectations will be NONE, or all will have an expected row count. We'd welcome comments from the Hibernate team. This could also be probably handled better by improving the Expectation interface. Oracle JDBC docs that explain the Oracle batching model: http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/oraperf.htm#... As expected, implementing this solution has resulted in drastical improvement in batch processing. -- 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

14 years, 5 months

4
11
0 / 0

[Hibernate-JIRA] Created: (ANN-644) @ManyToMany appears to ALWAYS generate a left outer join SQL

by Barry Davies (JIRA)

@ManyToMany appears to ALWAYS generate a left outer join SQL ------------------------------------------------------------ Key: ANN-644 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-644 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.3.0.ga Reporter: Barry Davies Priority: Minor Attachments: files.zip A collection mapping created using the @ManyToMany JPA annotation appears to create a left outer join SQL regardless of whether the joinColumn or inverseJoinColumn are marked nullable or not. This might be in error. Emmanuel asked for a JIRA issue to be created, so here we are. I have attached some files that can recreate what I believe to be the issue. The forum topic where this was brought up is: http://forum.hibernate.org/viewtopic.php?t=977936 -- 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

14 years, 5 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3160) Support one-to-many list associations with constraints on both (owner_id, position) and (child_id)

by Gail Badner (JIRA)

Support one-to-many list associations with constraints on both (owner_id, position) and (child_id) -------------------------------------------------------------------------------------------------- Key: HHH-3160 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3160 Project: Hibernate3 Issue Type: Sub-task Reporter: Gail Badner Assignee: Gail Badner The logic used for removing entities from one-to-many list associations can cause ConstraintViolationException will be thrown if there are constraints on both (owner_id, position) and (child_id) in the "collection table". If the association is on a join table, the "collection table" is the join table; otherwise, the "collection table" is the child entity table.. Currently, SchemaExport does not put a constraint on (owner_id, position) when exporting one-to-many list associations on a foreign key. SchemaExport should be updated to also export this constraint. See HHH-1268 for a description of how to reproduce this issue. For one-to-many list associations on a foreign key, the workaround is to either define the constraint on (owner_id, position) in the child entity table as deferred. If this is not on option for a particular Dialect, the constraint on (owner_id, position) will have to be excluded. For a one-to-many list association on a join table, the workaround is to either define the constraint on (child_id) in the join table as deferred. If this is not on option for a particular Dialect, the constraint on (child_id) will have to be excluded. -- 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

14 years, 5 months

4
6
0 / 0

[Hibernate-JIRA] Created: (HHH-5146) org.hibernate.util.IdentitySet.iterator() return Map.Entry instances instead of actual elements

by Nicklas Nordborg (JIRA)

org.hibernate.util.IdentitySet.iterator() return Map.Entry instances instead of actual elements ----------------------------------------------------------------------------------------------- Key: HHH-5146 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5146 Project: Hibernate Core Issue Type: Bug Components: core Reporter: Nicklas Nordborg Priority: Trivial Attachments: patch.txt By accident I used the IdentitySet implementation in my code and got ClassCastException:s when iterating over it. It turns out that the iterator() method returns Map.entrySet().iterator() instead of Map.keySet().iterator(). There is also a similar problem with the toArray() methods. I provide a patch. -- 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

14 years, 5 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3404) Regular expressions (regex) boolean operator in HQL's where clause: rlike in mysql, regexp_match in informix, ... (regression from hibernate2)

by Geoffrey De Smet (JIRA)

Regular expressions (regex) boolean operator in HQL's where clause: rlike in mysql, regexp_match in informix, ... (regression from hibernate2) ---------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-3404 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3404 Project: Hibernate3 Issue Type: New Feature Components: query-hql Affects Versions: 3.2.6 Reporter: Geoffrey De Smet Hibernate 2 supported the rlike boolean operator (at least for mysql): HB-1034. Hibernate3 currently doesn't. It turns out that most mainstream databases support regular expression patterns (independently from normal like patterns). Mysql: rlike where a.serial rlike '\d*' Informix: regexp_match() where regexp_match(a.serial, '\d*') Oracle: REGEXP_LIKE where REGEXP_LIKE(a.serial, '\d*') There have been several forum posts asking about this feature for hibernate3 btw: http://forum.hibernate.org/viewtopic.php?p=2391395 http://forum.hibernate.org/viewtopic.php?p=2375634 etc -- 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

14 years, 5 months

6
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3887) Envers hbm xml based configuration

by Helmut Pasch (JIRA)

Envers hbm xml based configuration ---------------------------------- Key: HHH-3887 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3887 Project: Hibernate Core Issue Type: Improvement Components: envers Affects Versions: 3.5 Environment: Hibernate: All Hibernate Versions including Envers as subproject Our Project: Hibernate 3.3.1, Spring 2.5.6, Spring DM 1.2.0, Swing, GWT, .... Reporter: Helmut Pasch Currently the tool library Envers can only be configured / mapped to java POJOs by annotations. We would appreciate if this mapping could be done by hbm xml files. Using this approach the POJO won't be bound to Envers annotations. They simply would be left as POJOs instead of transformed to JPA like Entity Beans. We use POJOs to directly serialize them to a client tier, e.g. a Swing or GWT client tier. If our POJOs have to rely on Envers annotations similar like JPA annotations we see only two options objects may leave the server tier. First by a copy to an annotation less value object, which is consuming performance and resources. Second by coping / using Envers / Hibernate libraries for reference purposes on the client tier. Both solutions are not very attractive compared to the very well working hbm xml approach Hibernate core ORM functionality provides us. It is our intention to reduce / eliminate in client server communication model transformations like coping objects or transforming them to other formats like XML, e.g. like web services does. The easiest way would be to just serialize the Java POJO objects. But never then less the client should only depend (logically) on the server API. It is not intended to rely on a specific server implementation. -- 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

14 years, 5 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3410) @OneToMany forces unique key in @JoinTable when inverseJoinColumns = @JoinColumn(unique=false)

by Kamil Morong (JIRA)

@OneToMany forces unique key in @JoinTable when inverseJoinColumns = @JoinColumn(unique=false) ---------------------------------------------------------------------------------------------- Key: HHH-3410 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3410 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.6 Environment: MySQL 5.0.51b, Hibernate Core 3.2.6 GA, Hibernate Annotations 3.3.1 GA Reporter: Kamil Morong Hi, I need to have this class composition with one to many relation: @Entity @Table(name="USER") public class User implements java.io.Serializable { private Long id; private String username; private String password; private Set<Role> roles = new LinkedHashSet<Role>(); public User() { } @Id @GeneratedValue(strategy = GenerationType.AUTO) @Column(name = "USER_ID") public Long getId() { return id; } public void setId(Long id) { this.id = id; } @Column(name="USERNAME", nullable=false, unique=true) public String getUsername() { return username; } public void setUsername(String userName) { this.username = userName; } @Column(name="PASSWORD", nullable=false) public String getPassword() { return password; } public void setPassword(String password) { this.password = password; } @CollectionOfElements @OneToMany(cascade={CascadeType.PERSIST, CascadeType.MERGE}) @JoinTable(name = "USER_ROLE", joinColumns = @JoinColumn(name = "USER_ID", unique=false), inverseJoinColumns = @JoinColumn(name = "ROLE_ID", unique=false)) @Cascade(org.hibernate.annotations.CascadeType.SAVE_UPDATE) @LazyCollection(LazyCollectionOption.FALSE) public Set<Role> getRoles() { return roles; } public void setRoles(Set<Role> roles) { this.roles = roles; } } @Entity @Table(name="ROLE") public class Role implements java.io.Serializable { private Long id; private String name; public Role() { } @Id @GeneratedValue(strategy = GenerationType.AUTO) @Column(name = "ROLE_ID") public Long getId() { return id; } public void setId(Long id) { this.id = id; } @Column(name="NAME", nullable=false, unique=true) public String getName() { return name; } public void setName(String name) { this.name = name; } } This will create db tables like SQL script CREATE TABLE `user` ( `USER_ID` BIGINT(20) NOT NULL AUTO_INCREMENT, `PASSWORD` VARCHAR(255) NOT NULL DEFAULT '', `USERNAME` VARCHAR(255) NOT NULL DEFAULT '', PRIMARY KEY (`USER_ID`), UNIQUE KEY `USERNAME` (`USERNAME`) ); CREATE TABLE `role` ( `ROLE_ID` BIGINT(20) NOT NULL AUTO_INCREMENT, `NAME` VARCHAR(255) NOT NULL DEFAULT '', PRIMARY KEY (`ROLE_ID`), UNIQUE KEY `NAME` (`NAME`) ); CREATE TABLE `user_role` ( `USER_ID` BIGINT(20) NOT NULL, `ROLE_ID` BIGINT(20) NOT NULL, PRIMARY KEY (`USER_ID`, `ROLE_ID`), UNIQUE KEY `ROLE_ID` (`ROLE_ID`), KEY `FKBC16F46A1174FFAB` (`ROLE_ID`), KEY `FKBC16F46AB69FC38B` (`USER_ID`), CONSTRAINT `FKBC16F46AB69FC38B` FOREIGN KEY (`USER_ID`) REFERENCES `user` (`USER_ID`), CONSTRAINT `FKBC16F46A1174FFAB` FOREIGN KEY (`ROLE_ID`) REFERENCES `role` (`ROLE_ID`) ); Tables USER and ROLE are right, but the join table USER_ROLE still have defined UNIQUE KEY `ROLE_ID` (`ROLE_ID`). This causes there cannot be one user with many roles. There must be some bug while generating database scheme. I am not able to remove unique key. -- 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

14 years, 6 months

7
8
0 / 0

[Hibernate-JIRA] Created: (HHH-3716) Sybase - null values for columns mapped as "boolean" are persisted as 0 (zero) instead of NULL

by Gail Badner (JIRA)

Sybase - null values for columns mapped as "boolean" are persisted as 0 (zero) instead of NULL ---------------------------------------------------------------------------------------------- Key: HHH-3716 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3716 Project: Hibernate Core Issue Type: Bug Components: core Environment: Sybase Reporter: Gail Badner Assignee: Gail Badner Fix For: 3.2.x, 3.3.x, 3.4 Null values for columns mapped as "boolean" are persisted as 0 (zero) instead of NULL. This happens because Hibernate persists a null Boolean value by calling: PreparedStatement.setNull( index, java.sql.Types.BIT ) The SQL code, java.sql.Types.BIT, is used because the Hibernate BooleanType defines its code as java.sql.Type.BIT. Sybase JDBC converts the null to 0, apparently because Sybase does not allow nullable bit columns. This can be reproduced using an annotations unit test, Java5FeaturesTest.testAutoboxing().. Sybase maps bit columns to tinyint, so when the unit test is executed, the column in the underlying table is actually of type tinyint, not bit. Sybase allows nullable tinyint columns, so there should be no problem persisting a null value as null. I've verified that changing the call to: PreparedStatement.setNull( index, java.sql.Types.TINYINT ) persists the null value without being converted to 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

14 years, 6 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HHH-4452) Sybase ingroes the last byte when persis a byte [] with BinaryType and the last byte is 0

by strong liu (JIRA)

Sybase ingroes the last byte when persis a byte [] with BinaryType and the last byte is 0 ------------------------------------------------------------------------------------------ Key: HHH-4452 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4452 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.0.Beta-1 Environment: hibernate-core trunk + sybase ase 15 Reporter: strong liu this issue can be repro with org.hibernate.test.annotations.LobTest.testBinary(). and that test will throw an ArrayIndexOutOfBoundsException. but if we change metadata[1] = (byte) 0; to metadata[1] = (byte) 2; (something else except 0), then the test will pass. -- 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

14 years, 6 months

4
5
0 / 0

[Hibernate-JIRA] Created: (ANN-692) StringClobType doesn't work with Sybase ASA

by Paul Middelkoop (JIRA)

StringClobType doesn't work with Sybase ASA ------------------------------------------- Key: ANN-692 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-692 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.3.0.ga Environment: Database: Adaptive Server Anywhere, version: 9.0.1.1753 JDBC: jConnect (TM) for JDBC(TM)/6.05(Build 26023) Reporter: Paul Middelkoop Sybase ASA doesn't support the CLOB datatype. However StringClobType works fine except when inserting a null value in the PreparedStatement. I fixed this by changing st.setNull(index, Types.CLOB) to st.setString(index, null). Maybe this can be added to the next release? -- 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

14 years, 6 months

5
4
0 / 0

[Hibernate-JIRA] Created: (HHH-3843) @Audited and @ManyToMany relation problem - after modyfing an Entity: org.hibernate.NonUniqueObjectException with message: "a different object with the same identifier value was already associated with the session ...

by Michał Maryniak (JIRA)

@Audited and @ManyToMany relation problem - after modyfing an Entity: org.hibernate.NonUniqueObjectException with message: "a different object with the same identifier value was already associated with the session ... ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-3843 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3843 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.3.1 Environment: envers.jar 1.2.0, Hibernate 3.3.1, postgresql-8.3, jboss-4.2.3 Reporter: Michał Maryniak Attachments: enverse.7z There is a problem with unidirectional @ManyToMany relation. This case is different than the one with inheritance: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3830. The example is trival and code is as simple as it can be. A single Person can have many roles, and one Role can by assigned to many Person entities. @Entity @Audited public class Person implements Serializable { (...) @ManyToMany public List<Role> getRoles() { return roles; } (...) } and @Entity @Audited public class Role implements Serializable { (...) } And here comes a use case: 1) I create role 'admin' 2) I create role 'user' 3) I create person 'john' and add him a role 'admin' 4) I edit 'john' and add him second role 'user' and I got an exception: org.hibernate.NonUniqueObjectException with message: "a different object with the same identifier value was already associated with the session: [Person_Role_AUD#{roles_id=1, Person_id=5, REV=DefaultRevisionEntity(id = 7, revisionDate = 2009-04-01 10:46:32)}]" If I add one role and remove the second one, or if I only remove a role - an Exception does not occur. I attached a zip file with this simple SEAM project generated by seam-gen 2.1.1 GA. I haven't included jar files, but project requires jar's "generated" with seam-gen (2.1.1) and following jar's have been replaced with new ones: 2008-06-13 13:09 313˙898 dom4j.jar 1.6.1 2009-03-23 13:01 285˙158 envers.jar 1.2.0-hibernate-3.3 2008-08-20 11:27 279˙714 hibernate-annotations.jar 3.4.0.GA 2008-08-20 11:31 66˙993 hibernate-commons-annotations.jar 3.1.0.GA 2008-08-20 12:19 119˙292 hibernate-entitymanager.jar 3.4.0.GA 2008-12-04 14:39 304˙236 hibernate-search.jar 3.1.0.GA 2008-09-10 14:01 62˙574 hibernate-validator.jar 3.1.0.GA 2008-09-10 13:27 2˙766˙130 hibernate.jar from hibernate-distribution-3.3.1.GA-dist 2008-06-13 13:09 13˙236 jta.jar 1.1 (from hibernate-distribution-3.3.1.GA-dist) 2008-12-04 14:41 818˙961 lucene-core.jar 2.4.0 701827 - 2008-10-05 16:44:37 2008-08-19 20:40 17˙384 slf4j-api.jar 1.5.2 If you wish - I can attach a file with my oryginal jar - but it would be a realy big file ;-) -- 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

14 years, 6 months

5
12
0 / 0

[Hibernate-JIRA] Created: (BVAL-24) What should be done when multiple META-INF/validation.xml are found?

by Emmanuel Bernard (JIRA)

What should be done when multiple META-INF/validation.xml are found? -------------------------------------------------------------------- Key: BVAL-24 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-24 Project: Bean Validation Issue Type: Task Components: spec-general 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

14 years, 6 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3434) hql insert doesn't work when inserting into a table with composite-id

by Ning Zhang (JIRA)

hql insert doesn't work when inserting into a table with composite-id ---------------------------------------------------------------------- Key: HHH-3434 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3434 Project: Hibernate3 Issue Type: Bug Components: query-hql Affects Versions: 3.2.6 Environment: 3.2.6GA, any database Reporter: Ning Zhang I have a table serving as an association table, so the Id of the table is just the ids from the linked tables. The mapping file looks like: <class name="UserPt" table="user_pt" > <composite-id> <key-property name="userId" type="java.lang.Long" column="user_id"/> <key-property name="ptId" type="java.lang.Long" column="pt_id"/> </composite-id> </class> And I need to run some HQL to insert the association into the table like: INSERT INTO UserPt(userId, ptId) SELECT user.id, pt.id FROM........... When I run this HQL, it gives an error saying: "can only generate ids as part of bulk insert with either sequence or post-insert style generators". I logged the bug in http://opensource.atlassian.com/projects/hibernate/browse/HHH-3400, but it is closed because I asked for a workaround. So this time I am not asking for anthing, just report 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

14 years, 6 months

5
8
0 / 0

[Hibernate-JIRA] Created: (HHH-4596) Bulk insertion with assigned identifiers

by Zoran Regvart (JIRA)

Bulk insertion with assigned identifiers ---------------------------------------- Key: HHH-4596 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4596 Project: Hibernate Core Issue Type: Patch Components: core Affects Versions: 3.5.0-Beta-2 Environment: latest hibernate, but tracing this since batch processing inception Reporter: Zoran Regvart Attachments: assigned-bulk-insert.patch supportsIdGenWithBulkInsertion method of HqlSqlWalker explicitly checks if the id generator is either SequenceGenerator or PostInsertIdentifierGenerator, I think this could be extended to include Assigned id generator, attached is the patch for that -- 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

14 years, 6 months

5
18
0 / 0

[Hibernate-JIRA] Created: (HHH-3440) 3.3.0 GA with MySQL 5.0 throws table validation exception

by Carlo Luib-Finetti (JIRA)

3.3.0 GA with MySQL 5.0 throws table validation exception --------------------------------------------------------- Key: HHH-3440 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3440 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.3.0.GA Environment: Hibernate 3.3.0 GA MySQL 5.0 JBoss 4.2.2 Reporter: Carlo Luib-Finetti Hibernate immediately throws an exception at application startup, when it does the schema validation. org.hibernate.HibernateException: Wrong column type in dpjw.assessment for column NOTES. Found: text, expected: longtext Comparing the sources of 3.2.0 with 3.3.0 I can see that someone set two java statements into comment. The 3.2 version of MySQLDialect.java looks like this: protected void registerVarcharTypes() { registerColumnType( Types.VARCHAR, "longtext" ); registerColumnType( Types.VARCHAR, 16777215, "mediumtext" ); registerColumnType( Types.VARCHAR, 65535, "text" ); registerColumnType( Types.VARCHAR, 255, "varchar($l)" ); } while the new 3.3.0 version is this: protected void registerVarcharTypes() { registerColumnType( Types.VARCHAR, "longtext" ); // registerColumnType( Types.VARCHAR, 16777215, "mediumtext" ); // registerColumnType( Types.VARCHAR, 65535, "text" ); registerColumnType( Types.VARCHAR, 255, "varchar($l)" ); } If I uncomment these (and others in the same Java file!), the validation process is ok. Is there any reason why these statements (and others!) were commented out??? -- 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

14 years, 6 months

6
7
0 / 0

[Hibernate-JIRA] Created: (HHH-3530) The code in the 3.3.1.GA subversion tag is not the code that's been released on the maven repository.jboss.org as 3.3.1.GA

by Geoffrey De Smet (JIRA)

The code in the 3.3.1.GA subversion tag is not the code that's been released on the maven repository.jboss.org as 3.3.1.GA -------------------------------------------------------------------------------------------------------------------------- Key: HHH-3530 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3530 Project: Hibernate Core Issue Type: Bug Components: build Affects Versions: 3.3.1 Reporter: Geoffrey De Smet Here's the proof: http://fisheye.jboss.org/browse/Hibernate/core/tags/hibernate-3.3.1.GA/co... contains the lines (44-45): registerColumnType( Types.CLOB, "longtext" ); registerColumnType( Types.CLOB, 16777215, "mediumtext" ); registerColumnType( Types.CLOB, 65535, "text" ); But the sources jar downloaded from http://repository.jboss.org/maven2/org/hibernate/hibernate-core/3.3.1.GA/... file org\hibernate\dialect\MySQLDialect.java so on my pc C:\Documents and Settings\gds\.m2\repository\org\hibernate\hibernate-core\3.3.1.GA\hibernate-core-3.3.1.GA-sources.jar!\org\hibernate\dialect\MySQLDialect.java has these lines (66-68) instead: registerColumnType( Types.CLOB, "longtext" ); // registerColumnType( Types.CLOB, 16777215, "mediumtext" ); // registerColumnType( Types.CLOB, 65535, "text" ); It's not just some copyright stuff that been added (giving it different line numbers), some lines are clearly commented out. Maybe untagged changes happened in other files too? -- 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

14 years, 6 months

4
4
0 / 0

[Hibernate-JIRA] Created: (HHH-3930) one-to-one causes redundant select query

by Martijn Dashorst (JIRA)

one-to-one causes redundant select query ---------------------------------------- Key: HHH-3930 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3930 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Reporter: Martijn Dashorst @Entity public class Address { @Id @GeneratedValue(strategy = GenerationType.AUTO) private Long id; @OneToOne(mappedBy = "address") private Customer customer; } @Entity public class Customer { @Id @GeneratedValue(strategy = GenerationType.AUTO) private Long id; @OneToOne(fetch = FetchType.EAGER, cascade = CascadeType.ALL) private Address address = new Address(); public Long getId() { return id; } public Address getAddress() { return address; } } This mapping causes 2 instead of the expected 1 query to retrieve a Customer and its Address from the db: select * from Customer customer0_ left outer join Address address1_ on customer0_.address_id=address1_.id where customer0_.id=? select * from Customer customer0_ left outer join Address address1_ on customer0_.address_id=address1_.id where customer0_.address_id=? Changing the mapping to a LAZY fetch type: @OneToOne(fetch = FetchType.LAZY, cascade = CascadeType.ALL) private Address address = new Address(); Causes 3 select queries instead of the expected 2 queries to retrieve a Customer (and its Address) from the db: select * from Customer customer0_ where customer0_.id=? select * from Address address0_ left outer join Customer customer1_ on address0_.id=customer1_.address_id where address0_.id=? select * from Customer customer0_ where customer0_.address_id=? The third select is superfluous because the relationship is already completely known: you already have the customer, so why not just set it on the address entity? Making the address field in Customer a @ManyToOne doesn't make a difference. Making the customer field in Address a @OneToMany does remove the extra select, but forces our model to change the relationship from Customer to List<Customer> where we *know* there'll be only 1 element. Apparently Hibernate can figure out the reverse relationship with a @ManyToOne - @OneToMany without the need for additional queries, can't this be extended to @OneToOne bidirectional relationships as well? -- 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

14 years, 6 months

4
3
0 / 0

[Hibernate-JIRA] Created: (HHH-4881) restrict polymorphic query results

by Domenico Loiacono (JIRA)

restrict polymorphic query results ---------------------------------- Key: HHH-4881 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4881 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.0-Beta-4 Environment: Hibernate 3.5.0-Beta-4, MySQL 5.1 Glassfish v3 Reporter: Domenico Loiacono I'm using JPA 2.0, Hibernate 3.5.0-Beta4, MySQL 5.1 on Glassfish v3. I want to limit the polymorphic query results using JPA 2.0 syntax (TYPE) : SELECT e FROM Employee e WHERE TYPE(e) IN (FullTime, Executive) but it seems that Hibernate 3.5.0-Beta4 doesn't support this syntax because in the generated sql query the 'type' keyword remains unmapped and MySQL throws an Exception: Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '(type(employee0_.id) in (5))' at line 1 So I tried with Criteria API: CriteriaBuilder criteriaBuilder = em.getCriteriaBuilder(); CriteriaQuery<Employee> criteria = criteriaBuilder.createQuery(Employee.class); Root<Employee> employee= criteria.from(Employee.class); criteria.where(employee.type().in(FullTime.class,Executive.class)); But I received an Exception: Caused by: java.lang.IllegalArgumentException: Unexpected call on EntityTypeExpression#render at org.hibernate.ejb.criteria.expression.PathTypeExpression.render(PathTypeExpression.java:48) at org.hibernate.ejb.criteria.predicate.InPredicate.render(InPredicate.java:164) at org.hibernate.ejb.criteria.QueryStructure.render(QueryStructure.java:258) at org.hibernate.ejb.criteria.CriteriaQueryImpl.render(CriteriaQueryImpl.java:340) at org.hibernate.ejb.criteria.CriteriaQueryCompiler.compile(CriteriaQueryCompiler.java:150) at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:416) at com.sun.enterprise.container.common.impl.EntityManagerWrapper.createQuery(EntityManagerWrapper.java:489) So I opened the PathTypeExpression class and in the render method I saw : public String render(CriteriaQueryCompiler.RenderingContext renderingContext) { // todo : is it valid for this to get rendered into the query itself? throw new IllegalArgumentException( "Unexpected call on EntityTypeExpression#render" ); } Then I switched to use Hibernate custom query syntax (class) : SELECT e FROM Employee e WHERE (e.class) IN (FullTime, Executive) Ok this works fine. But when I add a join with another entity (Department) that has the same TABLE_PER_CLASS inheritance strategy of entity Employee, I have a new problem: SELECT e FROM Employee e JOIN e.departments d WHERE d.code = 'D1' and (e.class) IN (FullTime, Executive) GRAVE: Column 'clazz_' in where clause is ambiguous Caused by: javax.persistence.PersistenceException: org.hibernate.exception.ConstraintViolationException: could not execute 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

14 years, 6 months

6
8
0 / 0

[Hibernate-JIRA] Created: (HHH-3133) ParameterParser incorrectly identifies positional paramters as output parameters

by Michael Cervantes (JIRA)

ParameterParser incorrectly identifies positional paramters as output parameters -------------------------------------------------------------------------------- Key: HHH-3133 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3133 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.5 Reporter: Michael Cervantes Any HQL that references a property with the text "call" in it will throw off the parser. For instance: <i>FROM Cdr WHERE account.id = ? AND callStart >= ? AND callStart < ?</i> kept giving me ordinal parameter errors because "callStart" tricks the parser into thinking there's an output parameter. -- 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

14 years, 6 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2866) The order of parameters is not maintained between HQL and SQL, but the parameters are inserted into the PreparedStatement in their HQL order.

by Benjamin Keil (JIRA)

The order of parameters is not maintained between HQL and SQL, but the parameters are inserted into the PreparedStatement in their HQL order. --------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-2866 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2866 Project: Hibernate3 Issue Type: Bug Components: query-hql Affects Versions: 3.2.5 Environment: Hibernate 3.2.5.ga; both with MySQLInnoDB and H2 dialects; both with annotations and hand written mapping files Reporter: Benjamin Keil Attachments: ReorderedParameters.java, ReorderedParameters.zip The HQL query from Assoc a where a.type.oid = ? and a.constituents[?].oid = ? gets translated into select reorderedp0_.oid as oid1_, reorderedp0_.type_oid as type2_1_ from Assoc reorderedp0_, Assoc_Topic constituen1_, Topic reorderedp2_ where reorderedp0_.oid=constituen1_.Assoc_oid and constituen1_.topic_index = ? and constituen1_.constituents_oid=reorderedp2_.oid and reorderedp0_.type_oid=? and reorderedp2_.oid=? Where clearly the first and second parameters (the index and the type) have been permuted. The relevant thread in the User forum is : http://forum.hibernate.org/viewtopic.php?t=979832 Attached are a java source file that demonstrates the error, and a zipped maven2 project that supplies the Hibernate, Hibernate-Annotation, H2, and Log4J dependencies. -- 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

14 years, 6 months

4
4
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-46) Race condition in manual index update

by Christian Bauer (JIRA)

Race condition in manual index update ------------------------------------- Key: HSEARCH-46 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-46 Project: Hibernate Search Issue Type: Bug Components: engine Reporter: Christian Bauer log.info("rebuilding Lucene index"); Class[] entityTypes = { Document.class, File.class, Comment.class, Faq.class}; EntityManager em = (EntityManager) Component.getInstance("entityManager"); FullTextSession ftSession = org.hibernate.search.Search.createFullTextSession( (Session) em.getDelegate() ); for (Class entityType : entityTypes) { for (Object o : ((Session) em.getDelegate()).createCriteria(entityType).list()) { ftSession.index(o); } } 08:23:39,419 INFO [WikiInit] rebuilding Lucene index 08:23:39,532 DEBUG [ManagedPersistenceContext] created seam managed persistence context from EntityManagerFactory 08:23:39,553 INFO [STDOUT] Hibernate: /* criteria query */ select this_.NODE_ID as NODE2_1_1_, this_.AREA_NR as AREA3_1_1_, this_.CREATED_BY_USER_ID as CREATED17_1_1_, this_.CREATED_ON as CREATED4_1_1_, this_.LAST_MODIFIED_BY_USER_ID as LAST18_1_1_, this_.LAST_MODIFIED_ON as LAST5_1_1_, this_.MENU_ITEM as MENU6_1_1_, this_.NAME as NAME1_1_, this_.PARENT_NODE_ID as PARENT20_1_1_, this_.READ_ACCESS_LEVEL as READ8_1_1_, this_.NODE_REVISION as NODE9_1_1_, this_.OBJ_VERSION as OBJ10_1_1_, this_.WIKINAME as WIKINAME1_1_, this_.WRITE_ACCESS_LEVEL as WRITE12_1_1_, this_.ENABLE_COMMENT_FORM as ENABLE14_1_1_, this_.ENABLE_COMMENTS as ENABLE15_1_1_, this_.NAME_AS_TITLE as NAME16_1_1_, node2_.NODE_ID as NODE2_1_0_, node2_.AREA_NR as AREA3_1_0_, node2_.CREATED_BY_USER_ID as CREATED17_1_0_, node2_.CREATED_ON as CREATED4_1_0_, node2_.LAST_MODIFIED_BY_USER_ID as LAST18_1_0_, node2_.LAST_MODIFIED_ON as LAST5_1_0_, node2_.MENU_ITEM as MENU6_1_0_, node2_.NAME as NAME1_0_, node2_.PARENT_NODE_ID as PARENT20_1_0_, node2_.READ_ACCESS_LEVEL as READ8_1_0_, node2_.NODE_REVISION as NODE9_1_0_, node2_.OBJ_VERSION as OBJ10_1_0_, node2_.WIKINAME as WIKINAME1_0_, node2_.WRITE_ACCESS_LEVEL as WRITE12_1_0_, node2_.DEFAULT_DOCUMENT_ID as DEFAULT19_1_0_, node2_.ENABLE_COMMENT_FORM as ENABLE14_1_0_, node2_.ENABLE_COMMENTS as ENABLE15_1_0_, node2_.NAME_AS_TITLE as NAME16_1_0_, node2_1_.CONTENT_TYPE as CONTENT1_2_0_, node2_1_.FILENAME as FILENAME2_0_, node2_1_.FILESIZE as FILESIZE2_0_, node2_1_.IMAGE_SIZE_X as IMAGE5_2_0_, node2_1_.IMAGE_SIZE_Y as IMAGE6_2_0_, node2_1_.IMAGE_THUMBNAIL as IMAGE7_2_0_, node2_.NODE_TYPE as NODE1_1_0_ from NODE this_ left outer join NODE node2_ on this_.PARENT_NODE_ID=node2_.NODE_ID left outer join NODE_FILE node2_1_ on node2_.NODE_ID=node2_1_.FILE_ID where this_.NODE_TYPE='DOCUMENT' 08:23:39,587 INFO [STDOUT] Hibernate: /* load org.jboss.seam.wiki.core.model.Node */ select node0_.NODE_ID as NODE2_1_1_, node0_.AREA_NR as AREA3_1_1_, node0_.CREATED_BY_USER_ID as CREATED17_1_1_, node0_.CREATED_ON as CREATED4_1_1_, node0_.LAST_MODIFIED_BY_USER_ID as LAST18_1_1_, node0_.LAST_MODIFIED_ON as LAST5_1_1_, node0_.MENU_ITEM as MENU6_1_1_, node0_.NAME as NAME1_1_, node0_.PARENT_NODE_ID as PARENT20_1_1_, node0_.READ_ACCESS_LEVEL as READ8_1_1_, node0_.NODE_REVISION as NODE9_1_1_, node0_.OBJ_VERSION as OBJ10_1_1_, node0_.WIKINAME as WIKINAME1_1_, node0_.WRITE_ACCESS_LEVEL as WRITE12_1_1_, node0_.DEFAULT_DOCUMENT_ID as DEFAULT19_1_1_, node0_.ENABLE_COMMENT_FORM as ENABLE14_1_1_, node0_.ENABLE_COMMENTS as ENABLE15_1_1_, node0_.NAME_AS_TITLE as NAME16_1_1_, node0_1_.CONTENT_TYPE as CONTENT1_2_1_, node0_1_.FILENAME as FILENAME2_1_, node0_1_.FILESIZE as FILESIZE2_1_, node0_1_.IMAGE_SIZE_X as IMAGE5_2_1_, node0_1_.IMAGE_SIZE_Y as IMAGE6_2_1_, node0_1_.IMAGE_THUMBNAIL as IMAGE7_2_1_, node0_.NODE_TYPE as NODE1_1_1_, node1_.NODE_ID as NODE2_1_0_, node1_.AREA_NR as AREA3_1_0_, node1_.CREATED_BY_USER_ID as CREATED17_1_0_, node1_.CREATED_ON as CREATED4_1_0_, node1_.LAST_MODIFIED_BY_USER_ID as LAST18_1_0_, node1_.LAST_MODIFIED_ON as LAST5_1_0_, node1_.MENU_ITEM as MENU6_1_0_, node1_.NAME as NAME1_0_, node1_.PARENT_NODE_ID as PARENT20_1_0_, node1_.READ_ACCESS_LEVEL as READ8_1_0_, node1_.NODE_REVISION as NODE9_1_0_, node1_.OBJ_VERSION as OBJ10_1_0_, node1_.WIKINAME as WIKINAME1_0_, node1_.WRITE_ACCESS_LEVEL as WRITE12_1_0_, node1_.DEFAULT_DOCUMENT_ID as DEFAULT19_1_0_, node1_.ENABLE_COMMENT_FORM as ENABLE14_1_0_, node1_.ENABLE_COMMENTS as ENABLE15_1_0_, node1_.NAME_AS_TITLE as NAME16_1_0_, node1_1_.CONTENT_TYPE as CONTENT1_2_0_, node1_1_.FILENAME as FILENAME2_0_, node1_1_.FILESIZE as FILESIZE2_0_, node1_1_.IMAGE_SIZE_X as IMAGE5_2_0_, node1_1_.IMAGE_SIZE_Y as IMAGE6_2_0_, node1_1_.IMAGE_THUMBNAIL as IMAGE7_2_0_, node1_.NODE_TYPE as NODE1_1_0_ from NODE node0_ left outer join NODE_FILE node0_1_ on node0_.NODE_ID=node0_1_.FILE_ID left outer join NODE node1_ on node0_.PARENT_NODE_ID=node1_.NODE_ID left outer join NODE_FILE node1_1_ on node1_.NODE_ID=node1_1_.FILE_ID where node0_.NODE_ID=? 08:23:39,654 INFO [STDOUT] Hibernate: /* criteria query */ select this_.COMMENT_ID as COMMENT1_4_0_, this_.CREATED_ON as CREATED2_4_0_, this_.DOCUMENT_ID as DOCUMENT9_4_0_, this_.FROM_USER_EMAIL as FROM3_4_0_, this_.FROM_USER_HOMEPAGE as FROM4_4_0_, this_.FROM_USER_NAME as FROM5_4_0_, this_.SUBJECT as SUBJECT4_0_, this_.COMMENT_TEXT as COMMENT7_4_0_, this_.OBJ_VERSION as OBJ8_4_0_ from COMMENTS this_ 08:23:39,662 INFO [STDOUT] Hibernate: /* criteria query */ select this_.FAQ_ID as FAQ1_7_0_, this_.ANSWER as ANSWER7_0_, this_.CREATED_ON as CREATED3_7_0_, this_.QUESTION as QUESTION7_0_, this_.RATING as RATING7_0_, this_.OBJ_VERSION as OBJ6_7_0_ from FAQ this_ 08:23:39,665 DEBUG [Work] committing transaction 08:23:39,807 ERROR [AssertionFailure] an assertion failure occured (this may indicate a bug in Hibernate) org.hibernate.annotations.common.AssertionFailure: Tries to read for update a index while a writer is accessedclass org.jboss.seam.wiki.core.model.Document at org.hibernate.search.backend.Workspace.getIndexReader(Workspace.java:54) at org.hibernate.search.backend.impl.lucene.LuceneWorker.remove(LuceneWorker.java:81) at org.hibernate.search.backend.impl.lucene.LuceneWorker.performWork(LuceneWorker.java:69) at org.hibernate.search.backend.impl.lucene.LuceneWorker.performWork(LuceneWorker.java:40) at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueProcessor.run(LuceneBackendQueueProcessor.java:36) at org.hibernate.search.backend.impl.BatchedQueueingProcessor.performWork(BatchedQueueingProcessor.java:116) at org.hibernate.search.backend.impl.PostTransactionWorkQueueSynchronization.afterCompletion(PostTransactionWorkQueueSynchronization.java:49) at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:136) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:342) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:95) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177) -- 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

14 years, 6 months

4
4
0 / 0

[Hibernate-JIRA] Created: (HHH-4723) Column in SQL query is returned as java.lang.Character

by Nick de Graeve (JIRA)

Column in SQL query is returned as java.lang.Character ------------------------------------------------------ Key: HHH-4723 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4723 Project: Hibernate Core Issue Type: Bug Components: query-sql Affects Versions: 3.3.1 Reporter: Nick de Graeve When I run this code sample: {{List data = session.createSQLQuery("select e.country_iso_code from agent.tbd3_Entry e where e.country_iso_code = 'BE'").list();}} {{Object row = data.get(0);}} {{System.out.print(row + ": " + row.getClass());}} I get this result: {{B: class java.lang.Character}} I expect to get a {{java.lang.String}} containing "BE", not just the 1st Character. The column country_is_code of table tbd3_entry is defined in Oracle as {{COUNTRY_ISO_CODE CHAR(2 BYTE)}} When I add a scalar with correct type I do get what I need: {{List data = session.createSQLQuery("select e.country_iso_code countryIsoCode from agent.tbd3_Entry e where e.country_iso_code = 'BE'").addScalar("countryIsoCode", Hibernate.STRING).list();}} {{Object row = data.get(0);}} {{System.out.print(row + ": " + row.getClass());}} results in {{BE: class java.lang.String}} -- 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

14 years, 6 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3313) Criteria + Property Projection + LockMode causes a NPE

by Christian Nelson (JIRA)

Criteria + Property Projection + LockMode causes a NPE ------------------------------------------------------ Key: HHH-3313 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3313 Project: Hibernate3 Issue Type: Bug Components: query-criteria Affects Versions: 3.2.6 Environment: Hibernate 3.2.6.ga, PostgreSQL 8.1 Reporter: Christian Nelson Attachments: hibernate-criteria-projection-lockmode-project.zip In converting a working HQL query to the Criteria API, we stumbled upon what looks very much like a bug. When combining a criteria with a projection and setting the lockmode (to read or upgrade), hibernate throws a NPE down in CriteriaLoader.applyLocks(). Here's a simplified snippet of the criteria that results in the exception: Criteria criteria = session.createCriteria(Article.class).add(Restrictions.ilike("title", "%frozen%")); criteria.createCriteria("moderation", "m").add(Restrictions.eq("approved", true)); criteria.setProjection(Projections.property("moderation")); criteria.setLockMode("m", LockMode.UPGRADE); assertions(criteria.list()); [The test case includes other attempts at building a similar criteria using different approaches.] And here's the stack trace: java.lang.NullPointerException at org.hibernate.loader.criteria.CriteriaLoader.applyLocks(CriteriaLoader.java:131) at org.hibernate.loader.Loader.preprocessSQL(Loader.java:201) at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1538) at org.hibernate.loader.Loader.doQuery(Loader.java:673) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236) at org.hibernate.loader.Loader.doList(Loader.java:2213) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2104) at org.hibernate.loader.Loader.list(Loader.java:2099) at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:94) at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1569) at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:283) There's already some talk on the web about this problem: * http://forum.hibernate.org/viewtopic.php?t=955525 * http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=78... I've created a simplified test case which includes the HQL version of the query (works), the Criteria version without lockmode (works), and then 3 failing tests illustrating the problem. The attached zip contains the test case and supporting files. The source code for the test case is also available via anonymous svn access (http://svn.carbonfive.com/public/christian/hibernate-criteria-projection-...). The test will run out of the box using maven against an h2database in-memory database with no setup. This combination of features doesn't seem that obscure so I'd expect it to work, or at the very least, report that it is not supported in a more graceful manner. -- 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

14 years, 6 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2304) Wrong type detection for sql type char(x) columns

by Markus Heiden (JIRA)

Wrong type detection for sql type char(x) columns ------------------------------------------------- Key: HHH-2304 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2304 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.ga Environment: Hibernate 3.2.0, Oracle 9.2, Oracle JDBC driver 10.2 Reporter: Markus Heiden Attachments: hibernate.zip When executing a sql query which returns columns of sql type char(x), a java.lang.Character is returned. This leads to returning just the first character of the value. In my eyes a String should be returned when the char(x) type has a width > 1. I wasn't able to determine whether this is a jdbc driver issue or a hibernate issue. When using sql type char(x) for columns of entities no such problems occur. Test case is 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

14 years, 6 months

8
13
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-395) Master/Slave configuration as outlined in Hibernate Search in Action does not work when shared location is on NFS

by Sam Doyle (JIRA)

Master/Slave configuration as outlined in Hibernate Search in Action does not work when shared location is on NFS ----------------------------------------------------------------------------------------------------------------- Key: HSEARCH-395 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-395 Project: Hibernate Search Issue Type: Bug Components: directory provider Affects Versions: 3.1.1.GA Reporter: Sam Doyle Priority: Critical https://forum.hibernate.org/viewtopic.php?f=9&t=998613&p=2416681#p2416681 There are many .nfs files being generated in slave locations and appear to be still held open by some part of the application since they fail to be cleaned up. 2009-08-21 10:51:08,696 ERROR [org.hibernate.search.util.FileHelper] Could not delete /location/to/slave/index/2/.nfs000000000085a3ce000016 7e -- 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

14 years, 6 months

4
8
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-159) Sort + Pagination returns wrong results.

by Jason Eacott (JIRA)

Sort + Pagination returns wrong results. ---------------------------------------- Key: HSEARCH-159 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-159 Project: Hibernate Search Issue Type: Bug Affects Versions: 3.0.1.GA Environment: hib 3.2.5ga Reporter: Jason Eacott Perhaps I am doing something wrong? Using the code below if I call getSearchResults("test",0,10); //returns incorrect data I get a different item at the head of the list than if I call getSearchResults("test",0,100);// (this one has correct data, total results for this search is 196 in my ndx & db) if I dont try to paginate the results then the sort items are in order and are correct. and if I paginate with just 1 result getSearchResults("test",0,1); and change the sort order I get the same result for each attempt: ie: Sort datesort=new Sort( new SortField( "date_time", SortField.STRING, true ) ); and Sort datesort=new Sort( new SortField( "date_time", SortField.STRING, false ) ); return the same entry - which is NOT the correct result either. This behavious seems to indicate that the data is being sorted after the limit is set and whats worse, if there are 50,000,000 results, even though I only want 10 and hibernate has already correctly hydrated those 10 (albeit the wrong 10) hibernatesearch then loops over all 50,000,000 hits and creates a new (empty) hibernate proxy object for each & discard all but 10! ... @Field(name="date_time", index=Index.UN_TOKENIZED, store=Store.NO) @DateBridge(resolution=Resolution.MINUTE) private Date publishDate; ... public List getSearchResults(Query query,int firstResult,int maxResults) { List result=null; Session sess=null; Transaction tx = null; try { sess=getSessionFactory().openSession(); FullTextSession fullTextSession = Search.createFullTextSession(sess); tx = fullTextSession.beginTransaction(); tx.begin(); org.hibernate.search.FullTextQuery hibQuery= fullTextSession.createFullTextQuery( query, FeedItem.class ); Sort datesort=new Sort( new SortField( "date_time", SortField.STRING, true ) ); hibQuery.setSort(datesort); Criteria dbCr=fullTextSession.createCriteria(FeedItem.class); hibQuery.setCriteriaQuery(dbCr); dbCr.setFirstResult(firstResult); dbCr.setMaxResults(maxResults); } long resultSize=hibQuery.getResultSize(); if (resultSize>0){ result = hibQuery.list() } tx.commit(); } finally { releaseSession(sess); tx=null; } log.debug("<getSearchResults"); return result; } -- 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

14 years, 6 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-3429) SQLQuery, advice user to always use addScalar if CHAR column are involved.

by Anthony Patricio (JIRA)

SQLQuery, advice user to always use addScalar if CHAR column are involved. -------------------------------------------------------------------------- Key: HHH-3429 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3429 Project: Hibernate3 Issue Type: Improvement Components: documentation Reporter: Anthony Patricio Priority: Minor see HHH-2220 If CHAR(2+) is involved in a SQLQuery and if addScalar isn't used, then the returned value is truncated which is very bad. There is no easy fix for this so a little advice in the documentation would be helpful. -- 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

14 years, 6 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2220) session.createSQLQuery(sql) translates database type CHAR(n) to Java type char instead of String

by Regis Pires Magalhaes (JIRA)

session.createSQLQuery(sql) translates database type CHAR(n) to Java type char instead of String ------------------------------------------------------------------------------------------------ Key: HHH-2220 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2220 Project: Hibernate3 Type: Bug Components: query-sql Versions: 3.2.0.ga Reporter: Regis Pires Magalhaes createSQLQuery() method translates database type CHAR(n) to Java type char instead of String when using setResultTransformer(Criteria.ALIAS_TO_ENTITY_MAP). That happens when I do not use addScalar(). And that is the only problem that I have found when not filling return types in advance. A workaround I have made is to concatenate the projected field with an empty string (''). See example below: ... query.setResultTransformer(Criteria.ALIAS_TO_ENTITY_MAP); String sqlQuery = "select s.name state from state s where s.name='PI' "; query = session.createSQLQuery(sqlQuery); ... result: [{STATE=P}] name field is CHAR(2) in database definition (PostgreSQL, HSQLDB and Oracle were tested). Note that it works when I concatenate the field used in projection with an empty string: ... String sqlQuery = "select s.name || '' state from state s where s.name='PI' "; ... result: [{STATE=PI}] -- 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

14 years, 6 months

8
7
0 / 0

[Hibernate-JIRA] Created: (HHH-2429) SQL Character Types Incorrectly mapped to Java objects

by Tyler Van Gorder (JIRA)

SQL Character Types Incorrectly mapped to Java objects ------------------------------------------------------ Key: HHH-2429 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2429 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.1 Environment: Hibernate 3.2.1, Oracle10g Reporter: Tyler Van Gorder We have a work flow that allows the user to enter an arbitrary SQL statement to be executed by our application. We pass those queries through session.createSQLQuery(). We ran into a problem with String literals, which are reported by Oracle (ResultSetMetaData) to be CHAR. Reading the JDBC API, CHAR is a fixed length string. Hibernate is incorrectly mapping this to a Character field. We ended up overriding the Oracle dialect with our own as follows: In our constructor, for a dialect that extends Oracle9iDialect: super() registerColumnType(Types.CHAR, "char($l)" ); registerHibernateType( Types.CHAR, Hibernate.STRING.getName() ); The HibernateType is the crucial one and we are overriding the behavior in the base "Dialect" class, so this appears that it would be a problem for all database variants that don't explicitly change this. Thanks. -- 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

14 years, 6 months

4
3
0 / 0

[Hibernate-JIRA] Created: (HCANN-10) JPA OneToOne(optional=true) not supported, supported alternative NotFound() is hibernate-proprietary!

by Bruno Melloni (JIRA)

JPA OneToOne(optional=true) not supported, supported alternative NotFound() is hibernate-proprietary! ----------------------------------------------------------------------------------------------------- Key: HCANN-10 URL: http://opensource.atlassian.com/projects/hibernate/browse/HCANN-10 Project: Hibernate Commons Annotations Issue Type: Bug Environment: Hibernate 3.3.1, annotations 3.4.0, MsSQL DB. Reporter: Bruno Melloni Rejected issue ANN-725 covers this partially. I might have misunderstood, but it seems the reason for rejecting is that @NotFound provides the same capability. All information I could find for JPA and other ORM tools indicates that this capability is supplied by @OneToOne(optional=true). Hibernate seems to be the lone ORM tool that requires the use of a proprietary annotation: @NotFound. @NotFound works, but the problem is that it makes the application no longer be pure-JPA. Not supporting pure-JPA outer joins would seem to be a major 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

14 years, 6 months

6
16
0 / 0

[Hibernate-JIRA] Created: (HHH-4854) Make constraint violation name extraction language neutral

by Jonas Olsson (JIRA)

Make constraint violation name extraction language neutral ---------------------------------------------------------- Key: HHH-4854 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4854 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.2.6 Environment: Oracle 8 or later Reporter: Jonas Olsson The ViolatedConstraintNameExtracter of Oracle8iDialect uses the following pattern for extracting the contraint violated: return extractUsingTemplate( "constraint (", ") violated", sqle.getMessage() ); and is highly error message language dependent. Changing to: return extractUsingTemplate( "(", ")", sqle.getMessage() ); would eliminate this while still getting the constraint name. -- 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

14 years, 6 months

3
5
0 / 0

[Hibernate-JIRA] Created: (HHH-3239) MarkerObject should be serializable when using with swf

by Goran Blankendal (JIRA)

MarkerObject should be serializable when using with swf ------------------------------------------------------- Key: HHH-3239 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3239 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.6 Environment: Hibernate 3.2.6 and Spring Webflow 2.0 Reporter: Goran Blankendal You get a java.io.NotSerializableException: org.hibernate.util.MarkerObject when using hibernate in a persistence context in SWF 2 See http://forum.springframework.org/showthread.php?t=51738 and http://forum.hibernate.org/viewtopic.php?t=985226 The MarkerObject should be serializable. -- 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

14 years, 6 months

4
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2774) Call ResultTransformer.transformList() even if the list argument is an empty list

by Christian Bauer (JIRA)

Call ResultTransformer.transformList() even if the list argument is an empty list --------------------------------------------------------------------------------- Key: HHH-2774 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2774 Project: Hibernate3 Issue Type: Improvement Components: core Reporter: Christian Bauer Priority: Trivial I have a case where a ResultTransformer is doing all the work in transformTuple() and always returns null from that method. The transformed target state is held internally in the ResultTransformer instance (I basically turn many tuples into one). Now I can't get this state out of the ResultTransformer because transformList() is not called after transformTuple(). It would be better if transformList() is called even if the list of tuples returned by transformTuple() is empty. -- 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

14 years, 6 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-4838) 2L-Querycache ImmutableNaturalKeyLookup not properly recognized as hasImmutableNaturalId() is called on wrong EntityMetamodel

by Guenther Demetz (JIRA)

2L-Querycache ImmutableNaturalKeyLookup not properly recognized as hasImmutableNaturalId() is called on wrong EntityMetamodel ----------------------------------------------------------------------------------------------------------------------------- Key: HHH-4838 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4838 Project: Hibernate Core Issue Type: Bug Components: caching (L2) Affects Versions: 3.5.0-Beta-3 Environment: 3.5.0-Beta3, HSQLDB, EHCache as 2L cache implementation Reporter: Guenther Demetz Attachments: TestImmutableNaturalId.jar If a entityclass with immutable naturalId has non-lazy properties (for instance a OneToOne association), then more entityPersisters are involved in the query as it becomes a join-query eager loading the associated entity. The method Loader#getResultFromQueryCache presumes that the first entityPersister in the array is the main entity class. boolean isImmutableNaturalKeyLookup = queryParameters.isNaturalKeyLookup() && getEntityPersisters()[0].getEntityMetamodel().hasImmutableNaturalId(); Debugging attached testcase you can see indeed that getEntityPersisters()[0] returns SingleTableEntityPersister(hello.D) which is the persister of the associated entity, not the main one! Consequently the query is not considered as isImmutableNaturalKeyLookup, despite fullfilling all conditions. Here my output (with enabled p6spy): 11:53:15,651 INFO Version:37 - Hibernate Annotations 3.5.0.Beta1 11:53:15,690 INFO Environment:563 - Hibernate 3.5.0-Beta-3 11:53:15,694 INFO Environment:596 - hibernate.properties not found 11:53:15,700 INFO Environment:774 - Bytecode provider name : javassist 11:53:15,706 INFO Environment:655 - using JDK 1.4 java.sql.Timestamp handling 11:53:15,863 INFO Version:38 - Hibernate EntityManager 3.5.0.Beta1 11:53:16,356 INFO AnnotationBinder:446 - Binding entity from annotated class: hello.A 11:53:16,424 INFO EntityBinder:471 - Bind entity hello.A on table A 11:53:16,526 INFO AnnotationBinder:446 - Binding entity from annotated class: hello.D 11:53:16,527 INFO EntityBinder:471 - Bind entity hello.D on table D 11:53:16,686 WARN Ejb3Configuration:943 - hibernate.connection.autocommit = false break the EJB3 specification 11:53:16,702 INFO HibernateSearchEventListenerRegister:75 - Unable to find org.hibernate.search.event.FullTextIndexEventListener on the classpath. Hibernate Search is not enabled. 11:53:16,718 INFO DriverManagerConnectionProvider:64 - Using Hibernate built-in connection pool (not for production use!) 11:53:16,719 INFO DriverManagerConnectionProvider:65 - Hibernate connection pool size: 20 11:53:16,720 INFO DriverManagerConnectionProvider:68 - autocommit mode: false 11:53:16,921 INFO DriverManagerConnectionProvider:103 - using driver: com.p6spy.engine.spy.P6SpyDriver at URL: jdbc:hsqldb:hsql://localhost 11:53:16,922 INFO DriverManagerConnectionProvider:109 - connection properties: {user=sa, password=****, autocommit=false, release_mode=after_transaction} 11:53:17,002 INFO SettingsFactory:117 - RDBMS: HSQL Database Engine, version: 1.8.0 11:53:17,004 INFO SettingsFactory:118 - JDBC driver: HSQL Database Engine Driver, version: 1.8.0 11:53:17,068 INFO Dialect:223 - Using dialect: org.hibernate.dialect.HSQLDialect 11:53:17,082 INFO JdbcSupportLoader:79 - Disabling contextual LOB creation as JDBC driver reported JDBC version [3] less than 4 11:53:17,085 INFO TransactionFactoryFactory:62 - Transaction strategy: org.hibernate.transaction.JDBCTransactionFactory 11:53:17,089 INFO TransactionManagerLookupFactory:80 - No TransactionManagerLookup configured (in JTA environment, use of read-write or transactional second-level cache is not recommended) 11:53:17,090 INFO SettingsFactory:169 - Automatic flush during beforeCompletion(): disabled 11:53:17,091 INFO SettingsFactory:173 - Automatic session close at end of transaction: disabled 11:53:17,097 INFO SettingsFactory:188 - Scrollable result sets: enabled 11:53:17,098 INFO SettingsFactory:196 - JDBC3 getGeneratedKeys(): disabled 11:53:17,099 INFO SettingsFactory:204 - Connection release mode: after_transaction 11:53:17,101 INFO SettingsFactory:231 - Default batch fetch size: 1 11:53:17,103 INFO SettingsFactory:235 - Generate SQL with comments: disabled 11:53:17,104 INFO SettingsFactory:239 - Order SQL updates by primary key: disabled 11:53:17,105 INFO SettingsFactory:243 - Order SQL inserts for batching: disabled 11:53:17,107 INFO SettingsFactory:410 - Query translator: org.hibernate.hql.ast.ASTQueryTranslatorFactory 11:53:17,114 INFO SettingsFactory:251 - Query language substitutions: {} 11:53:17,115 INFO SettingsFactory:256 - JPA-QL strict compliance: enabled 11:53:17,121 INFO SettingsFactory:261 - Second-level cache: enabled 11:53:17,130 INFO SettingsFactory:265 - Query cache: enabled 11:53:17,143 INFO SettingsFactory:395 - Cache region factory : org.hibernate.cache.impl.bridge.RegionFactoryCacheProviderBridge 11:53:17,144 INFO RegionFactoryCacheProviderBridge:61 - Cache provider: net.sf.ehcache.hibernate.SingletonEhCacheProvider 11:53:17,150 INFO SettingsFactory:275 - Optimize cache for minimal puts: disabled 11:53:17,151 INFO SettingsFactory:284 - Structured second-level cache entries: disabled 11:53:17,151 INFO SettingsFactory:374 - Query cache factory: org.hibernate.cache.StandardQueryCacheFactory 11:53:17,165 INFO SettingsFactory:313 - Statistics: disabled 11:53:17,166 INFO SettingsFactory:317 - Deleted entity synthetic identifier rollback: disabled 11:53:17,166 INFO SettingsFactory:332 - Default entity-mode: pojo 11:53:17,167 INFO SettingsFactory:336 - Named query checking : enabled 11:53:17,167 INFO SettingsFactory:340 - Check Nullability in Core (should be disabled when Bean Validation is on): disabled 11:53:17,240 INFO SessionFactoryImpl:197 - building session factory 11:53:17,260 WARN ConfigurationFactory:131 - No configuration found. Configuring ehcache from ehcache-failsafe.xml found in the classpath: jar:file:/home/pb00067/Desktop/ehcache-1.7.1/lib/ehcache-core-1.7.1.jar!/ehcache-failsafe.xml 11:53:17,361 WARN SingletonEhCacheProvider:92 - Could not find a specific ehcache configuration for cache named [hello.A]; using defaults. 11:53:17,566 WARN SingletonEhCacheProvider:92 - Could not find a specific ehcache configuration for cache named [hello.D]; using defaults. 11:53:17,661 INFO SchemaExport:226 - Running hbm2ddl schema export 11:53:17,663 INFO SchemaExport:251 - exporting generated schema to database p6spy - 1264416797664|0|0|commit|| p6spy - 1264416797670|1|0|statement alter table A drop constraint FK41F7BDC12E p6spy - 1264416797672|0|0|statement drop table A if exists p6spy - 1264416797673|0|0|statement drop table D if exists p6spy - 1264416797674|1|0|statement drop table hibernate_sequences if exists p6spy - 1264416797675|1|0|statement create table A (oid bigint not null, name varchar(255), version integer not null, assSingleD_oid bigint, primary key (oid), unique (name)) p6spy - 1264416797676|0|0|statement create table D (oid bigint not null, version integer not null, primary key (oid)) p6spy - 1264416797678|1|0|statement alter table A add constraint FK41F7BDC12E foreign key (assSingleD_oid) references D p6spy - 1264416797679|1|0|statement create table hibernate_sequences ( sequence_name varchar(255), sequence_next_hi_value integer ) 11:53:17,679 INFO SchemaExport:268 - schema export complete 11:53:17,684 INFO UpdateTimestampsCache:57 - starting update timestamps cache at region: org.hibernate.cache.UpdateTimestampsCache 11:53:17,686 WARN SingletonEhCacheProvider:92 - Could not find a specific ehcache configuration for cache named [org.hibernate.cache.UpdateTimestampsCache]; using defaults. 11:53:17,689 INFO StandardQueryCache:75 - starting query cache at region: org.hibernate.cache.StandardQueryCache 11:53:17,690 WARN SingletonEhCacheProvider:92 - Could not find a specific ehcache configuration for cache named [org.hibernate.cache.StandardQueryCache]; using defaults. 11:53:17,841 DEBUG ConnectionManager:444 - opening JDBC connection p6spy - 1264416797874|6|1|statement select sequence_next_hi_value from hibernate_sequences where sequence_name = 'A' p6spy - 1264416797876|0|1|statement insert into hibernate_sequences (sequence_name, sequence_next_hi_value) values ('A', 0) p6spy - 1264416797878|0|1|statement update hibernate_sequences set sequence_next_hi_value = 1 where sequence_next_hi_value = 0 and sequence_name = 'A' p6spy - 1264416797879|0|1|commit|| p6spy - 1264416797915|0|0|statement insert into A (assSingleD_oid, name, version, oid) values ('', 'name1', 0, 1) 11:53:17,919 DEBUG UpdateTimestampsCache:66 - Pre-invalidating space [A] p6spy - 1264416797931|0|0|commit|| 11:53:17,934 DEBUG UpdateTimestampsCache:81 - Invalidating space [A], timestamp: 5179051204337665 11:53:17,974 DEBUG StandardQueryCache:127 - checking cached query results in region: org.hibernate.cache.StandardQueryCache 11:53:17,975 DEBUG StandardQueryCache:132 - query results were not found in cache p6spy - 1264416797978|0|0|statement select this_.oid as oid0_1_, this_.assSingleD_oid as assSingleD4_0_1_, this_.name as name0_1_, this_.version as version0_1_, d2_.oid as oid1_0_, d2_.version as version1_0_ from A this_ left outer join D d2_ on this_.assSingleD_oid=d2_.oid where ( this_.name='name1' ) p6spy - 1264416797981|-1||resultset|oid=1, oid=null 11:53:17,985 DEBUG StandardQueryCache:94 - caching query results in region: org.hibernate.cache.StandardQueryCache; timestamp=5179051204546560 11:53:17,992 DEBUG StandardQueryCache:127 - checking cached query results in region: org.hibernate.cache.StandardQueryCache 11:53:17,993 DEBUG StandardQueryCache:185 - Checking query spaces for up-to-dateness: [A] 11:53:17,994 DEBUG UpdateTimestampsCache:102 - [A] last update timestamp: 5179051204337665, result set timestamp: 5179051204546560 11:53:17,994 DEBUG StandardQueryCache:142 - returning cached query results 11:53:17,997 INFO SessionFactoryImpl:908 - closing -- 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

14 years, 7 months

6
29
0 / 0

[Hibernate-JIRA] Created: (EJB-276) Support for CLOB not working for DB2 when table per concrete class is being used

by breako (JIRA)

Support for CLOB not working for DB2 when table per concrete class is being used -------------------------------------------------------------------------------- Key: EJB-276 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-276 Project: Hibernate Entity Manager Type: Bug Versions: 3.2.1 Reporter: breako Hi, This came up in the forums: http://forum.hibernate.org/viewtopic.php?p=2344008#2344008 Sample code: Two Pojos @Entity public class Person { private int i; @Identity public int getI() { return i; } public void setI(int i){ this.i = i; } } @Entity public class Employee extends Person{ @Basic(fetch=FetchType.LAZY) @Lob public String getClobAttr() { return clobAttr; } public void setClobAttr(String clobAttr) { this.clobAttr = clobAttr; } } Simple test: public static void main (String args[]) { Query queryImpl = em.createQuery(" from Person"); List list = queryImpl.getResultList(); } This will generate SQL select person0_.clobAttr as clobAttr1 from (select nullif(0,0) as clobAttr from TPerson union all select clobAttr from TEmployee) person0_ which chucks the exception: DB2 SQL error: SQLCODE: -415, SQLSTATE: 42825, SQLERRMC: null I think the SQL hibernate should generate should be: select person0_.clobAttr as clobAttr1 from (select cast(null as CLOB) as clobAttr from TPerson union all select clobAttr from TEmployee) person0_ -- 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

14 years, 7 months

5
4
0 / 0

[Hibernate-JIRA] Created: (BVAL-193) Publish javax.validation:validation-api to Maven central

by Pete Muir (JIRA)

Publish javax.validation:validation-api to Maven central -------------------------------------------------------- Key: BVAL-193 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-193 Project: Bean Validation Issue Type: Task Reporter: Pete Muir -- 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

14 years, 7 months

2
2
0 / 0

[Hibernate-JIRA] Created: (BVAL-200) Validator cannot find validation.xml unless is placed in /WEB-INF/classes/META-INF

by Cris Webber (JIRA)

Validator cannot find validation.xml unless is placed in /WEB-INF/classes/META-INF ---------------------------------------------------------------------------------- Key: BVAL-200 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-200 Project: Bean Validation Issue Type: Bug Components: ri-general - obsolete go to HValidator Environment: Java SE 1.5.0_10; Hibernate Validator 4.0.2.GA. Reporter: Cris Webber Priority: Minor Hibernate Validator requires that the validation.xml file is placed in the META-INF directory in order to load it. In the case of having a WAR file, placing the validation.xml file in /META-INF (at the same level as the WEB-INF directory) does not work, as Hibernate Validator cannot find the file there. Placing the file in /WEB-INF/classes/META-INF worked fine. I believe this is just a workaround and Hibernate Validator should be able to find validation.xml in /META-INF. -- 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

14 years, 7 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3248) org.hibernate.cache.EhCache.toMap() throws NullPointerException

by Kenny MacLeod (JIRA)

org.hibernate.cache.EhCache.toMap() throws NullPointerException --------------------------------------------------------------- Key: HHH-3248 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3248 Project: Hibernate3 Issue Type: Bug Components: caching (L2) Affects Versions: 3.2.6 Reporter: Kenny MacLeod The toMap() method of org.hibernate.cache.EhCache is not null-safe. The expression cache.get( key ).getObjectValue() Will throw a NPE, since get(key) may return a null in cases where the key exists in the cache, but the value does not, e.g. if it has expired. This should either check for the null, or the list of keys should be obtained using getKeysWithExpiredCheck(), rather than just getKeys(). -- 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

14 years, 7 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3747) Memory leak in EnumType class.

by Paweł Kępka (JIRA)

Memory leak in EnumType class. ------------------------------ Key: HHH-3747 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3747 Project: Hibernate Core Issue Type: Bug Components: core, metamodel Reporter: Paweł Kępka Priority: Critical Holding enum values in static enumValues map in EnumType class causes memory leaks on application server where hibernate is loaded by application server's common classloader (like for default configuration of JBoss4). SoftReference or SessionFactory based caching should be used instead. -- 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

14 years, 7 months

6
19
0 / 0

[Hibernate-JIRA] Created: (HHH-3836) composite-element with null columns in map is ignored

by Benoit Goudreault-Emond (JIRA)

composite-element with null columns in map is ignored ----------------------------------------------------- Key: HHH-3836 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3836 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.0.SP1 Environment: 3.3.0 SP1, noticed with Oracle and H2 but probably happens with all databases Reporter: Benoit Goudreault-Emond Attachments: patate.zip When a composite element with all properties set to NULL is inserted in a map of the said composite element, the data gets inserted to the database but is never retreived when reloading the entity. For instance, with an entity @Entity public class TestEntity { @Id private int id; @CollectionOfElements private Map<String, AccessPeriod> roleAccesses = new HashMap<String, AccessPeriod>(); // boilerplate getters/setters/etc omitted } And AccessPeriod being @Embeddable public class AccessPeriod { public Date startDate; public Date endDate; } If you insert in the map an AccessPeriod with both startDate and endDate set to null and persist the TestEntity, an entry is inserted in the auxiliary table, but when getting the TestEntity back, the map is empty. You get the same problem with a mapping file. This used to work in Hibernate 2.1--I found this out while porting some code to 3.3. See the attached example. You'll need to include Hibernate and h2 (com.h2database:h2 1.0.20061217) on your classpath to run it with the given jdbc.properties, but feel free to change it. -- 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

14 years, 7 months

5
6
0 / 0

[Hibernate-JIRA] Created: (HCANN-18) Make sure that the build enforces JDK 5 compilation just like Core does today

by Emmanuel Bernard (JIRA)

Make sure that the build enforces JDK 5 compilation just like Core does today ----------------------------------------------------------------------------- Key: HCANN-18 URL: http://opensource.atlassian.com/projects/hibernate/browse/HCANN-18 Project: Hibernate Commons Annotations Issue Type: Task Affects Versions: 3.2.0 Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik -- 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

14 years, 7 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3318) Allow omitting varchar limit by default in PostgreSQL

by Luke Maurer (JIRA)

Allow omitting varchar limit by default in PostgreSQL ----------------------------------------------------- Key: HHH-3318 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3318 Project: Hibernate3 Issue Type: New Feature Components: core Environment: Hibernate 3.2.6, PostgreSQL 8.3.1 Reporter: Luke Maurer Priority: Minor Essentially, what I'd like is for a String without a given maximum length be mapped as a varchar or text rather than a varchar(255) as is now the case. The maximum doesn't do anything to improve performance or storage efficiency in PostgreSQL, so varchar(255) merely imposes an arbitrary constraint. It would be more idiomatic to use varchar where no limit is given, leaving varchar(n) for cases where the length is limited as a business rule rather than an implementation detail. (Naturally, one can always use @Lob where it's actually *important* that the column be a varchar or text. So this is definitely 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

14 years, 7 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3244) Implement support NVARCHAR type

by Sergey Derugo (JIRA)

Implement support NVARCHAR type -------------------------------- Key: HHH-3244 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3244 Project: Hibernate3 Issue Type: New Feature Components: core Environment: al Reporter: Sergey Derugo JDBC 4.0 allows supports NVARCHAR type, but Hibernate doesn't handle it. Please implement support for NVarchar -- 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

14 years, 8 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HHH-2955) Unnecessary version updates in two cases.

by Sławomir Wojtasiak (JIRA)

Unnecessary version updates in two cases. ----------------------------------------- Key: HHH-2955 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2955 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Environment: JDK 5.0 Reporter: Sławomir Wojtasiak Attachments: HibernateTest.zip I found two situations where hibernate generates unnecessary version updates. Let's illustrate it with a simple example: Session session = SessionFactory.getSession(); Transaction transaction = session.getTransaction(); transaction.begin(); Article a = new Article(); a.setName( "atricle" ); ********************************************* *** Quantity is the owner of the relation *** ********************************************* Quantity q = new Quantity(); q.setName( "quantity" ); q.setArticle( a ); a.getQuantities().add( q ); session.persist( a ); session.flush(); ***** Hibernate generates following SQLs ***** Hibernate: select nextval ('hibernate_sequence') Hibernate: select nextval ('hibernate_sequence') Hibernate: insert into Article (name, version, id) values (?, ?, ?) Hibernate: insert into Quantity (article_id, name, version, id) values (?, ?, ?, ?) ********************************************** a.getQuantities().clear(); session.flush(); *** Hibernate generates following SQLs *** Hibernate: update Article set name=?, version=? where id=? and version=? This update of version field is performed because collection of quantities is marked as dirty, but Article entity is not relation owner so nothing change in database after this clear. Should it works like this? It looks like a bug because database remain unchanged so version changing is unnecessary in my opinion. ****************************************** session.clear(); **** SECOND PROBLEM *** Now I generate true copy of persisted objects. Notice that I use HashSet instead of PersistSet which was set during persist operation. This operation is similar to merging objects prepared by SOAP, during communication with remote client for example. *********************** Article a1 = new Article(); a1.setId( a.getId() ); a1.setName( a.getName() ); a1.setVersion( a.getVersion() ); Quantity q1 = new Quantity(); q1.setArticle( a1 ); q1.setName( q.getName() ); q1.setVersion( q.getVersion() ); q1.setId( q.getId() ); a1.getQuantities().add( q1 ); a1 = (Article)session.merge( a1 ); session.flush(); ***** This operation generates following SQLs ***** Hibernate: select article0_.id as id0_1_, article0_.name as name0_1_, article0_.version as version0_1_, quantities1_.article_id as article4_3_, quantities1_.id as id3_, quantities1_.id as id1_0_, quantities1_.article_id as article4_1_0_, quantities1_.name as name1_0_, quantities1_.version as version1_0_ from Article article0_ left outer join Quantity quantities1_ on article0_.id=quantities1_.article_id where article0_.id=? Hibernate: update Article set name=?, version=? where id=? and version=? It looks like problem is located in replaceElements() method of CollectgionType class (or somewhere near it). Maybe I'm wrong but this collection was checked for changes during merge operation (See this select above.) so why it remains dirty if it contains the same data as database?. I checked this issue on other JPA implementations (OpenJPA for example) and version is not incremented after similar merge operation. ***************************************************** transaction.rollback(); -- 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

14 years, 8 months

3
2
0 / 0

[Hibernate-JIRA] Created: (EJB-318) PostUpdate callback not called after update on a collection / association (@OneToMany for example)

by Aghnar von Salza (JIRA)

PostUpdate callback not called after update on a collection / association (@OneToMany for example) -------------------------------------------------------------------------------------------------- Key: EJB-318 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-318 Project: Hibernate Entity Manager Issue Type: Bug Components: EntityManager Environment: Hibernate core3.2.5, entityManager 3.3.1, annotation 3.3.0, oracle 9i Reporter: Aghnar von Salza Environment is Weblogic 10 (J2EE 5), with Hibernate used as JPA provider There is no PostUpdate callback on an entity when one of its collections of other Entities (for example annoted with @OneToMany) is updated (i mean when one entity element is added or removed). JPA specification says that a postUpate must be called after the update of at least one data of an entity. I think we have to consider that a collection of other entities can be considered as 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

14 years, 8 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3051) NPE while query.list on a Native SQL, using L2 cache

by Amit Kapoor (JIRA)

NPE while query.list on a Native SQL, using L2 cache ---------------------------------------------------- Key: HHH-3051 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3051 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Environment: Hibernate 3.2.5ga Database Oracle 9i Jdk - 1.4.2_13 EHCache 1.2.3 / OsCache 2.1 both Reporter: Amit Kapoor I get an NPE when i try to execute a native query. Below is the excerpt of the code that throws NPE: String sqlQuery = "select emp_id, emp_first_name from employee_mt"; SQLQuery query = session.createSQLQuery(sqlQuery); query.setCacheable(true).setCacheRegion("TEST_REGION"); query.addScalar("emp_id"); query.addScalar("emp_first_name"); List list = query.list(); query.list() throws the following NPE: java.lang.NullPointerException at org.hibernate.type.TypeFactory.disassemble(TypeFactory.java:451) at org.hibernate.cache.StandardQueryCache.put(StandardQueryCache.java:83) at org.hibernate.loader.Loader.putResultInQueryCache(Loader.java:2194) at org.hibernate.loader.Loader.listUsingQueryCache(Loader.java:2138) at org.hibernate.loader.Loader.list(Loader.java:2096) at org.hibernate.loader.custom.CustomLoader.list(CustomLoader.java:289) at org.hibernate.impl.SessionImpl.listCustomQuery(SessionImpl.java:1695) at org.hibernate.impl.AbstractSessionImpl.list(AbstractSessionImpl.java:142) at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java:152) at poc.hibernate.caching.QueryCaching.fireNativeSql(QueryCaching.java:112) at poc.hibernate.caching.QueryCaching.fireQuery(QueryCaching.java:38) at poc.hibernate.caching.QueryCaching.main(QueryCaching.java:27) I tried tracing through the Hibernate code code and saw that the types[] in the at the time of execution of types[i].disassemble( row[i], session, owner ) (TypeFactory.disassemble()) was holding both the types as null. However before reaching that piece of code CustomLoader.autoDiscoverTypes(resultset) had already resolved the resultTypes to appropriate values. Hope this helps. -- 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

14 years, 8 months

3
5
0 / 0

[Hibernate-JIRA] Created: (HCANN-20) Update pom to use the new distributationManagement information

by Hardy Ferentschik (JIRA)

Update pom to use the new distributationManagement information -------------------------------------------------------------- Key: HCANN-20 URL: http://opensource.atlassian.com/projects/hibernate/browse/HCANN-20 Project: Hibernate Commons Annotations Issue Type: Task Affects Versions: 3.2.0 Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 3.2.x http://community.jboss.org/wiki/MavenGettingStarted-Developers -- 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

14 years, 8 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-4580) Possible Sybase bug causes AssertionFailure in QueryByExampleTest

by Strong Liu (JIRA)

Possible Sybase bug causes AssertionFailure in QueryByExampleTest ----------------------------------------------------------------- Key: HHH-4580 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4580 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.0-Beta-2, 3.5.0.Beta-1, 3.3.2, 3.2.4.sp1 Environment: sybase 15 Reporter: Strong Liu Test QueryByExampleTest.testJunctionNotExpressionQBE fails due to a possible bug in Sybase 15. The same test passes for Sybase 12.5. The test expects two records as a result for a query, but it gets 3. After some debugging with the query that Hibernate generated, I end up with these two simpler ones: select id from Componentizable where not (name like ? and subName1 like ?) select id from Componentizable where not (name like 'hibernate' and subName1 like 'ope%') The first one returns three records, while the second returns two. The interesting part is that if I replace the first parameter in the first query by a hardcoded value ("hibernate"), it still returns 3 records. That means that the problem is probably with the binding of JDBC parameters containing a wildcard % . -- 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

14 years, 8 months

2
5
0 / 0

[Hibernate-JIRA] Created: (ANN-814) OneToOne Unidirectional Support

by Rachit (JIRA)

OneToOne Unidirectional Support ------------------------------- Key: ANN-814 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-814 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.4.0.GA Environment: Oracle 10g, Java 1.5 Reporter: Rachit Priority: Blocker I tried hard for unidirectional OneToOne mapping as below: @Entity @Table(name = "PARTY") public class Party{ private Person person; private String key; @OneToOne(fetch = FetchType.EAGER, cascade = CascadeType.ALL,) @PrimaryKeyJoinColumn(name = "PARTY_ID", referencedColumnName = "PERSON_PARTY_ID") public Person getPerson() { return person; } public void setPerson(Person person) { this.person = person; } @Id @GeneratedValue(generator = "system-uuid") @GenericGenerator(name = "system-uuid", strategy = "uuid") @Column(name = "PARTY_ID", nullable = false) public String getKey() { return key; } private void setKey(String key) { this.key = key; } } and it is one-to-one mapped to Person as: @Entity(name = "Person") @Table(name = "PERSON") public class Person { private String key; @Id @Column(name = "PERSON_PARTY_ID") public String getKey() { return key; } public void setKey(String key) { this.key = key; } } Now in Person, I deliberately dont have sysUUID as generated as then it generates a unique value for person and the association gets lost. With this mapping hibernate throws the following exception : Caused by: org.hibernate.id.IdentifierGenerationException: ids for this class must be manually assigned before calling save(): Person. I read and saw constrained="true" being used in mapping files, which I couldnt use as there is no attribute like it in OneToOne annotation. Please help me out on 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

14 years, 8 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-4727) Add option to specify foreign key name on table with shared primary key used in one-to-one relationship

by Pavla Nováková (JIRA)

Add option to specify foreign key name on table with shared primary key used in one-to-one relationship --------------------------------------------------------------------------------------------------------- Key: HHH-4727 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4727 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.3.2 Reporter: Pavla Nováková There is currently no way to specify (user friendly) foreign key name on table with shared primary key used in One-to-One mapping. The most intuitive way would be to accept @ForeignKey on property level (see the comment in the code below) or on entity level (similar way to usage in joined inheritance) or last option may be add parameter in foreign generator. {code} @Entity public class ExampleEntity implements Serializable { @Id @GenericGenerator(name = "foreign-generator", strategy = "foreign", parameters=@Parameter(name="property", value="parentExampleEntity")) @GeneratedValue(generator = "foreign-generator") private Long id; ... @PrimaryKeyJoinColumn @OneToOne(fetch=FetchType.LAZY, optional=false) @org.hibernate.annotations.ForeignKey(name="parent_entity_fk") // this is currently ignored private ParentExampleEntity parentExampleEntity; ... } {code} -- 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

14 years, 8 months

2
1
0 / 0

[Hibernate-JIRA] Created: (ANN-667) Foreign key name on @OneToOne

by Immo Heikkinen (JIRA)

Foreign key name on @OneToOne ----------------------------- Key: ANN-667 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-667 Project: Hibernate Annotations Issue Type: Bug Components: binder Affects Versions: 3.3.0.ga Environment: Hibernate Core 3.2.5.GA , Hibernate Annotations 3.3.0.GA, Sybase ASE 15 Reporter: Immo Heikkinen Priority: Minor Attachments: Child.java, Parent.java Foreign key constraint name cannot be changed using @org.hibernate.annotations.ForeignKey on a @OneToOne with foreign key. It doesn't matter which class is annotated with @ForeignKey. Please find the test case as an attachment. Original thread on the user forum: http://forum.hibernate.org/viewtopic.php?p=2367400 -- 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

14 years, 8 months

4
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2225) NPE when eager fetching joined component with native SQL query

by Christian Bauer (JIRA)

NPE when eager fetching joined component with native SQL query -------------------------------------------------------------- Key: HHH-2225 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2225 Project: Hibernate3 Type: Bug Components: query-sql Versions: 3.2.0.ga Reporter: Christian Bauer Priority: Minor Item -> many-to-one -> User -> joined component -> billingAddress This: result = session.createSQLQuery("select {i.*}, {u.*}, {ba.*} from ITEM i" + " join USERS u on i.SELLER_ID = u.USER_ID" + " left join BILLING_ADDRESS ba on u.USER_ID = ba.USER_ID" + " where u.USERNAME = :uname") .addEntity("i", Item.class) .addJoin("u", "i.seller") .addJoin("ba", "u.billingAddress") fails with: java.lang.NullPointerException at org.hibernate.loader.DefaultEntityAliases.<init>(DefaultEntityAliases.java:37) at org.hibernate.loader.custom.sql.SQLQueryReturnProcessor.generateCustomReturns(SQLQueryReturnProcessor.java:283) at org.hibernate.loader.custom.sql.SQLCustomQuery.<init>(SQLCustomQuery.java:129) at org.hibernate.engine.query.NativeSQLQueryPlan.<init>(NativeSQLQueryPlan.java:43) at org.hibernate.engine.query.QueryPlanCache.getNativeSQLQueryPlan(QueryPlanCache.java:114) at org.hibernate.impl.AbstractSessionImpl.getNativeSQLQueryPlan(AbstractSessionImpl.java:137) at org.hibernate.impl.AbstractSessionImpl.list(AbstractSessionImpl.java:142) at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java:150) -- 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

14 years, 8 months

15
24
0 / 0

[Hibernate-JIRA] Created: (EJB-385) JPA method of merge failed to insert deleted records from database

by Hari (JIRA)

JPA method of merge failed to insert deleted records from database ------------------------------------------------------------------- Key: EJB-385 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-385 Project: Hibernate Entity Manager Issue Type: Improvement Components: EntityManager Affects Versions: 3.2.0.ga Environment: 3.2.6.ga, Weblogic,JPA, Windows Reporter: Hari The following is my requirement. Suppose i have a record in database with id say, 12. i have retrieved this using a JPQL query and convert it into a transfer object ,done some processing and going to remerge this after converting it to a new entity but the id set in the new entity is same as old one ie 12. Now just before calling entityManger.merge i have deleted the record with id 12 from database. The issue is the merge opeartion is not inserting the record in database at all. But if the id set in the entity is one which is never occured in the database,the merge operation will insert the record with the id set from teh application. Is there any work around/fix for this issue. Regards Harikrishnan R -- 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

14 years, 8 months

2
1
0 / 0

[Hibernate-JIRA] Created: (ANN-853) Implement JPA 2.0 annotation support

by Emmanuel Bernard (JIRA)

Implement JPA 2.0 annotation support ------------------------------------ Key: ANN-853 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-853 Project: Hibernate Annotations Issue Type: New Feature Components: binder Reporter: Emmanuel Bernard Fix For: 3.5 -- 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

14 years, 8 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-4066) JPA compatibility problem

by Albert Kurucz (JIRA)

JPA compatibility problem ------------------------- Key: HHH-4066 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4066 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.3.2 Environment: Hibernate Core 3.3.2, problem is independent from database type (actually appeared with Derby 10.4.2) Reporter: Albert Kurucz POJO Entity with 100% JPA annotations, as long as the Class did not implement the Map interface everything worked fine (save to and load from database). After the Class implemented the Map interface, during object persistence, 'get' was called with '$type$' parameter, and 'get' responded with IllegalArgumentException (in accordance to its design). Workaround implemented: get now responds to this call by returning getClass().getName() BUT Hibernate should not need this workaround if it is 100% JPA compliant. On the above example the Map interface of the Entity Class had no connection with persisted variables, only transients. In the JPA spec there is no restriction what I know of, which would disallow the implementation of Map by an Entity Class. In the JPA spec there is no requirement what I know of, which would require and Entity Class which implement the Map interface to implement the Map interface in any special way (like 'get' responding to '$type$'). Correct me if I am wrong. -- 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

14 years, 8 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3223) PersistentMap.remove() incorrect on uninitialized, non-extra-lazy map

by Michael Newcomb (JIRA)

PersistentMap.remove() incorrect on uninitialized, non-extra-lazy map --------------------------------------------------------------------- Key: HHH-3223 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3223 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.3.0.CR1 Reporter: Michael Newcomb Please have a look at PersistentMap.remove() and compare it to PersistentMap.put(). The put() was fixed HHH-2476 and the same fix needs to be applied to remove(). Please refer to HHH-2584 for the patch: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2584 Copied from HHH-2584: Essentially, an uninitialized PersistentMap loses the first remove() into it if defined as non-extra-lazy. The underlying cause is the code in PersistentMap#remove() which attempts to readElementByIndex(). In the case of non-extra-lazy, readElementByIndex() returns the UNKNOWN marker object which is supposed to be used to signal that the delegate map is now initialized and to remove the element directly from the map. Long story short, PersistentMap#remove() does not properly check the return value from readElementByIndex() and react accordingly. WORKAROUND: Have a copy of PersistentMap.java in your source tree with the patch applied... Thanks! -- 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

14 years, 8 months

4
8
0 / 0

[Hibernate-JIRA] Created: (HHH-3459) NullPointerException in Formatter.isFunctionName with certain SQL when pretty format is used

by Scott Feldstein (JIRA)

NullPointerException in Formatter.isFunctionName with certain SQL when pretty format is used -------------------------------------------------------------------------------------------- Key: HHH-3459 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3459 Project: Hibernate3 Issue Type: Bug Components: query-sql Affects Versions: 3.2.6 Reporter: Scott Feldstein A NullPointerException is thrown when hibernate.show_sql=true && hibernate.format_sql=true while exec'ing sql with quotes around the stmt: (taken from an embedded groovy script) --------- def sess = getSession() def HQL = """ (select count(*) from TABLE) """ sess .createSQLQuery(HQL) .list() ------------ This is valid SQL and is typically used in my app as such: (select count(*) from TABLE1) UNION ALL (select count(*) from TABLE2) ... Here is the stack trace in hibernate: java.lang.NullPointerException at org.hibernate.pretty.Formatter.isFunctionName(Formatter.java:342) at org.hibernate.pretty.Formatter.openParen(Formatter.java:323) at org.hibernate.pretty.Formatter.format(Formatter.java:134) at org.hibernate.jdbc.AbstractBatcher.format(AbstractBatcher.java:410) at org.hibernate.jdbc.AbstractBatcher.log(AbstractBatcher.java:404) at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:482) at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:423) at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:139) at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1547) at org.hibernate.loader.Loader.doQuery(Loader.java:673) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236) at org.hibernate.loader.Loader.doList(Loader.java:2220) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2104) at org.hibernate.loader.Loader.list(Loader.java:2099) at org.hibernate.loader.custom.CustomLoader.list(CustomLoader.java:289) at org.hibernate.impl.SessionImpl.listCustomQuery(SessionImpl.java:1695) at org.hibernate.impl.AbstractSessionImpl.list(AbstractSessionImpl.java:142) at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java:152) -- 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

14 years, 8 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-4830) @PostLoad -> LazyInitializationException: illegal access to loading collection ond a @OneToMany with FetchType.EAGER

by Cédric Templie (JIRA)

@PostLoad -> LazyInitializationException: illegal access to loading collection ond a @OneToMany with FetchType.EAGER -------------------------------------------------------------------------------------------------------------------- Key: HHH-4830 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4830 Project: Hibernate Core Issue Type: Bug Reporter: Cédric Templie I faced this issue without using JBoss although I found it on JBoss JIRA: https://jira.jboss.org/jira/browse/JBAS-5474 As a result I really think that it is an hibernate issue. -- 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

14 years, 8 months

2
1
0 / 0

[Hibernate-JIRA] Created: (EJB-364) Composite PK and @GeneratedValue

by Radosław Smogura (JIRA)

Composite PK and @GeneratedValue -------------------------------- Key: EJB-364 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-364 Project: Hibernate Entity Manager Issue Type: Bug Affects Versions: 3.3.2.GA Environment: Hibernate 3.2.6 Glassfish PostgreSQL Reporter: Radosław Smogura Priority: Critical [code] For class like this @Entity @IdClass(FooId.class) /* Seq / Table generator */ public class Foo { int id1; int id2; @Id public getId1() { return id1; } public setId1(....); @Id @GeneratedValue(strategy=AUTO/IDENTITY/SEQUENCE/TABLE) public int getId2() { return id2; } public void setId2(.....); } [/code] Id1 is set manully, but id2 is unchanged i this situation hibernate doesn't generates PK and tries to insert NULL causing error. Specification requires assigning of generated value with @Id properties. Part 2.4.1 defines two types of PKs simple and composite and part 9.1.9 says about PKs in generally. (SEQ or IDENTITY is specification depended, but PostgreSQL support it and Hibernate should support it too). -- 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

14 years, 8 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3028) Memory consumption when query cache is enabled

by Markus Heiden (JIRA)

Memory consumption when query cache is enabled ---------------------------------------------- Key: HHH-3028 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028 Project: Hibernate3 Issue Type: Bug Components: caching (L2), core Affects Versions: 3.2.5 Environment: Hibernate 3.2.5, Oracle 9i Reporter: Markus Heiden As discussed in the hibernate-dev mailing list from 9.11.2007 to 12.11.2007 this bug describes a memory consumption issue which is located in ActionQueue/EntityAction. Some snippets from ActionQueue: private ArrayList executions; public void execute(Executable executable) { final boolean lockQueryCache = session.getFactory().getSettings().isQueryCacheEnabled(); if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) { executions.add( executable ); } ... } This code leads to a kind of memory leak, because if the "executable" is added to "executions", the related entity which is referenced from the "executable" is prevented from being garbage collected until the transaction ends. So if one needs to insert large amounts of transient objects in one transaction, there is no chance to get rid of the inserted objects by flushing and evicting them, if e.g. the query cache is enabled. One solution to this problem might be to rework the above "if" condition to only add objects to "executions" if this is really needed. The problem is to determine when it is really needed. Some snippets from EntityAction (which implements Executable): private final Object instance; public final Serializable getId() { if ( id instanceof DelayedPostInsertIdentifier ) { return session.getPersistenceContext().getEntry( instance ).getId(); } return id; } public final Object getInstance() { return instance; } Another solution might be to set the reference to the related entity (field "instance" in EntityAction) to null after flushing. This does not prevent "executions" from being filled, but the related entities might be garbage collected and so the memory consumption is acceptable. The problem is that subclasses of EntityAction use the "instance" field for post transaction work. The are currently two workarounds to this problems: 1) To always disable the query cache 2) To use shorter transactions Workaround 1 is not really acceptable, because it prohibits the use of a very useful feature. Workaround 2 is sometimes acceptable but not wanted in most cases, because it breaks transactional safety. -- 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

14 years, 8 months

8
12
0 / 0

[Hibernate-JIRA] Created: (HHH-3876) collection [] was not processed by flush() triggering for unknown reasons

by Mark Derricutt (JIRA)

collection [] was not processed by flush() triggering for unknown reasons ------------------------------------------------------------------------- Key: HHH-3876 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3876 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5 Reporter: Mark Derricutt We've started to notice the following exceptions being triggered from Hibernate 3.5.0-SNAPSHOT (built locally), but only under certain circumstances (editing a specific user, whilst being logged into the application as a specific user). After stepping through both our application and hibernate through the whole update/commit process being run, I can't find anything that would be causing this problem. During processing, I see calls to org.hibernate.engine.Collections#prepareCollectionForUpdate for CollectionEntry[smx3.schema.PartyRole.agreementsFrom#2006094] (and other elements in the same collection) which is listed in the trace below. The collection which triggers the exception isn't consistently the same one, but seems to be localized to 4-5 different collections, I've also noticed that if I single-stepping through the process, if sometimes completes fine, which may indicate some race conditions somewhere. As I'm not entirely sure why the exception is being thrown, I'm not sure if this is a problem with Hibernate, or something wrong in our application somewhere. Is there anyway I can identify why a collection entry wouldn't have been processed (and what does "processed" actually mean?). 24.04.2009 15:57:33.180 *ERROR* [btpool0-1] org.hibernate.AssertionFailure an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session) org.hibernate.AssertionFailure: collection [smx3.schema.PartyRole.agreementsFrom] was not processed by flush() at org.hibernate.engine.CollectionEntry.postFlush(CollectionEntry.java:228) at org.hibernate.event.def.AbstractFlushingEventListener.postFlush(AbstractFlushingEventListener.java:356) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1031) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:369) at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:88) at com.atomikos.icatch.jta.Sync2Sync.beforeCompletion(Sync2Sync.java:73) at com.atomikos.icatch.imp.TransactionStateHandler.commit(TransactionStateHandler.java:253) at com.atomikos.icatch.imp.CompositeTransactionImp.doCommit(CompositeTransactionImp.java:509) at com.atomikos.icatch.imp.CompositeTerminatorImp.commit(CompositeTerminatorImp.java:138) at com.atomikos.icatch.jta.TransactionImp.commit(TransactionImp.java:297) at com.atomikos.icatch.jta.TransactionManagerImp.commit(TransactionManagerImp.java:608) at com.atomikos.icatch.jta.UserTransactionManager.commit(UserTransactionManager.java:148) at smx3.envers.TransactionFilter.afterHandle(TransactionFilter.java:242) at org.restlet.Filter.handle(Filter.java:197) at org.restlet.Filter.doHandle(Filter.java:150) at org.restlet.Filter.handle(Filter.java:195) at org.restlet.Filter.doHandle(Filter.java:150) at org.restlet.Filter.handle(Filter.java:195) at org.restlet.Filter.doHandle(Filter.java:150) at com.noelios.restlet.StatusFilter.doHandle(StatusFilter.java:130) at org.restlet.Filter.handle(Filter.java:195) at org.restlet.Filter.doHandle(Filter.java:150) at org.restlet.Filter.handle(Filter.java:195) at com.noelios.restlet.ChainHelper.handle(ChainHelper.java:124) at com.noelios.restlet.application.ApplicationHelper.handle(ApplicationHelper.java:112) at org.restlet.Application.handle(Application.java:341) at org.restlet.ext.wadl.WadlApplication.handle(WadlApplication.java:705) at org.restlet.Filter.doHandle(Filter.java:150) at org.restlet.Filter.handle(Filter.java:195) at org.restlet.Router.handle(Router.java:504) at org.restlet.Filter.doHandle(Filter.java:150) at org.restlet.Filter.handle(Filter.java:195) at org.restlet.Router.handle(Router.java:504) at org.restlet.Filter.doHandle(Filter.java:150) at org.restlet.Filter.handle(Filter.java:195) at com.noelios.restlet.ChainHelper.handle(ChainHelper.java:124) at org.restlet.Component.handle(Component.java:673) at org.restlet.Server.handle(Server.java:331) at com.noelios.restlet.ServerHelper.handle(ServerHelper.java:68) at com.noelios.restlet.http.HttpServerHelper.handle(HttpServerHelper.java:147) at com.noelios.restlet.ext.servlet.ServerServlet.service(ServerServlet.java:881) at nz.co.smx.rest.RestActivator$RestActivatorClassLoaderServlet.service(RestActivator.java:182) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) at org.ops4j.pax.web.service.internal.HttpServiceServletHandler.handle(HttpServiceServletHandler.java:51) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:722) at org.ops4j.pax.web.service.internal.HttpServiceContext.handle(HttpServiceContext.java:87) at org.ops4j.pax.web.service.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:63) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:842) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450) 24.04.2009 15:57:33.183 *WARN* [btpool0-1] atomikos Unexpected error in beforeCompletion: org.hibernate.AssertionFailure: collection [smx3.schema.PartyRole.agreementsFrom] was not processed by flush() at org.hibernate.engine.CollectionEntry.postFlush(CollectionEntry.java:228) at org.hibernate.event.def.AbstractFlushingEventListener.postFlush(AbstractFlushingEventListener.java:356) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1031) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:369) at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:88) at com.atomikos.icatch.jta.Sync2Sync.beforeCompletion(Sync2Sync.java:73) at com.atomikos.icatch.imp.TransactionStateHandler.commit(TransactionStateHandler.java:253) at com.atomikos.icatch.imp.CompositeTransactionImp.doCommit(CompositeTransactionImp.java:509) at com.atomikos.icatch.imp.CompositeTerminatorImp.commit(CompositeTerminatorImp.java:138) at com.atomikos.icatch.jta.TransactionImp.commit(TransactionImp.java:297) at com.atomikos.icatch.jta.TransactionManagerImp.commit(TransactionManagerImp.java:608) at com.atomikos.icatch.jta.UserTransactionManager.commit(UserTransactionManager.java:148) at smx3.envers.TransactionFilter.afterHandle(TransactionFilter.java:242) at org.restlet.Filter.handle(Filter.java:197) at org.restlet.Filter.doHandle(Filter.java:150) at org.restlet.Filter.handle(Filter.java:195) at org.restlet.Filter.doHandle(Filter.java:150) at org.restlet.Filter.handle(Filter.java:195) at org.restlet.Filter.doHandle(Filter.java:150) at com.noelios.restlet.StatusFilter.doHandle(StatusFilter.java:130) at org.restlet.Filter.handle(Filter.java:195) at org.restlet.Filter.doHandle(Filter.java:150) at org.restlet.Filter.handle(Filter.java:195) at com.noelios.restlet.ChainHelper.handle(ChainHelper.java:124) at com.noelios.restlet.application.ApplicationHelper.handle(ApplicationHelper.java:112) at org.restlet.Application.handle(Application.java:341) at org.restlet.ext.wadl.WadlApplication.handle(WadlApplication.java:705) at org.restlet.Filter.doHandle(Filter.java:150) at org.restlet.Filter.handle(Filter.java:195) at org.restlet.Router.handle(Router.java:504) at org.restlet.Filter.doHandle(Filter.java:150) at org.restlet.Filter.handle(Filter.java:195) at org.restlet.Router.handle(Router.java:504) at org.restlet.Filter.doHandle(Filter.java:150) at org.restlet.Filter.handle(Filter.java:195) at com.noelios.restlet.ChainHelper.handle(ChainHelper.java:124) at org.restlet.Component.handle(Component.java:673) at org.restlet.Server.handle(Server.java:331) at com.noelios.restlet.ServerHelper.handle(ServerHelper.java:68) at com.noelios.restlet.http.HttpServerHelper.handle(HttpServerHelper.java:147) at com.noelios.restlet.ext.servlet.ServerServlet.service(ServerServlet.java:881) at nz.co.smx.rest.RestActivator$RestActivatorClassLoaderServlet.service(RestActivator.java:182) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) at org.ops4j.pax.web.service.internal.HttpServiceServletHandler.handle(HttpServiceServletHandler.java:51) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:722) at org.ops4j.pax.web.service.internal.HttpServiceContext.handle(HttpServiceContext.java:87) at org.ops4j.pax.web.service.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:63) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:842) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450) -- 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

14 years, 9 months

5
5
0 / 0

[Hibernate-JIRA] Created: (HBX-1081) Generation of meta attributes for composite-id

by Anders Reinhardt Hansen (JIRA)

Generation of meta attributes for composite-id ---------------------------------------------- Key: HBX-1081 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1081 Project: Hibernate Tools Issue Type: Improvement Components: reverse-engineer Affects Versions: 3.2.beta11 Environment: All, not related to platform. Reporter: Anders Reinhardt Hansen Priority: Minor The ReverseEngineeringStrategy has a method; "public Map tableToMetaAttributes(TableIdentifier tableIdentifier)" This method returns a Map of meta tags which will be put inside the class node of the hbm files that are generated. It would be a nice addition if we could have a method like this which placed meta tags inside the composite id node. the method could be called "public Map tableToMetaAttributesForCompositeId(TableIdentifier tableIdentifier)" An example of the problem is shown in the below example; <class name="XXX1" table="XXX1"> <meta attribute="generated-class">XXX1Base</meta>  <composite-id name="XXX2" class="XXX2"> <meta attribute="generated-class">XXX2Base</meta>  <key-property name="propertyXXX" type="int"> <column name="ColoumnXXX" /> </key-property> <key-property name="YYY" type="int"> <column name="ColoumnYYY" /> </key-property> </composite-id> ... </class> The issue was discussed on the forum in topic http://forum.hibernate.org/viewtopic.php?t=989476 -- 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

14 years, 9 months

5
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3305) hbm2ddl: MS SQL Server 2005 defaults to Clustered Index on PK, lets use PRIMARY KEY NONCLUSTERED for hbm2ddl as a more reasonable default

by Jim Doyle (JIRA)

hbm2ddl: MS SQL Server 2005 defaults to Clustered Index on PK, lets use PRIMARY KEY NONCLUSTERED for hbm2ddl as a more reasonable default ------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-3305 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3305 Project: Hibernate3 Issue Type: Bug Components: metamodel Affects Versions: 3.2.1 Reporter: Jim Doyle In SQL Server 2005, PRIMARY KEY defaults to creating a Clustered Index for the PK column at table creation time. To confirm this behaviour Please see: http://msdn.microsoft.com/en-us/library/ms188066.aspx This default behaviour is un-desireable for a number of reasons: 1. No other databases default to a clustered IDX at the PK ; Not DB2, nor Oracle nor MySQL 2. There may only be ONE clustered IDX per table. By using this as a default makes it difficult for the app developer or DBA to quickly add or change the once-per-table opportunity to use the cluster to improve query performance. 3. The default cluster index that Microsoft applies seems only to benefit naive SQL server users with little to no DBA skills. Table insert of new rows onto a Clustered Index PK is always very fast and while this optimization may be impressive if your problem space is rapidly inserting new data into large tables, this optimization is often an antipattern to users with more plausible query patterns such as scan by non-primary key date, numeric amounts or alphabetical data. 4. Defaulting the PK to clustered creates SUBSTANTIAL burden for a DBA when the Clustered Index needs to be removed from the PK to be deployed on other columns on the table. As an example of the burden that this creates, for EACH TABLE one must: - Discover all tables and columns that link back to the table in question through FOREIGN KEY - Drop all foreign keys - Drop the PK - Add the PK back, with NONCLUSTERED - Put back all the dropped Foreign keys 5. Additional arguments against supporting Microsoft's unusual default is given here: http://tonesdotnetblog.wordpress.com/2008/05/26/twelve-tips-for-optimisin... (Please See Section 2: Use Clustered Index). I propose ANY ONE of the following enhancements to the DDL generator for the SQL Server 2005 Dialect: 1. Change the generated SQL from colname coltype PRIMARY KEY TO colname coltype PRIMARY KEY NONCLUSTERED such that PK index generate conforms the the usual, sensible defaults of other database products. 2. Use a Properties attribute (i.e. hibernate.hbm2ddl.dialect.mssql.use_non_clustered_pk) that is evaluated at hbm2ddl runtime that will emit 'NONCLUSTERED' to the PK clause. If this Property is not defined, the hbm2ddl will simply emit PRIMARY KEY as it does now and MS SQL Server will use its peculiar and annoying default. -- 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

14 years, 9 months

3
2
0 / 0

[Hibernate-JIRA] Created: (ANN-758) map key type no longer inferred correctly, throws exception at runtime

by David Mansfield (JIRA)

map key type no longer inferred correctly, throws exception at runtime ---------------------------------------------------------------------- Key: ANN-758 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-758 Project: Hibernate Annotations Issue Type: Bug Components: binder Affects Versions: 3.3.1.GA Environment: hib. 3.2, annotaions 3.3.1GA, em 3.3.1GA, oracle 10r2, tomcat 5.5, linux, spring 2.0 Reporter: David Mansfield Attachments: hib-anno-set-map-key-type.patch after upgrading from annotations 3.3.0GA to 3.3.1GA, my mapped collection (ManyToMany) is broken. i've identified the commit that broke it: http://fisheye.jboss.com/browse/Hibernate/annotations/trunk/src/java/org/... The issue is that unless the type is given now expliticly in the @MapKey's @Type, the code now assumes a 'Serializable' type, and attempts to deserialize an object stream from the database column value. the exact exception is: java.io.StreamCorruptedException: invalid stream header at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:764) at java.io.ObjectInputStream.<init>(ObjectInputStream.java:277) at org.hibernate.util.SerializationHelper$CustomObjectInputStream.<init>(SerializationHelper.java:252) at org.hibernate.util.SerializationHelper.deserialize(SerializationHelper.java:209) at org.hibernate.util.SerializationHelper.deserialize(SerializationHelper.java:240) at org.hibernate.type.SerializableType.fromBytes(SerializableType.java:82) at org.hibernate.type.SerializableType.get(SerializableType.java:39) at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:163) ... The fix is simple: if @Type is NOT given in the @MapKey annotation, keep the old behavior which at least tries to set the type, even if it may not work in all situations. The attached patch fixes the problem for me. In my particular situation, the map key type is a java.lang.Enum. Here's what my annotated property looks like: @ManyToMany @JoinTable( name="chargeback_owner" ,joinColumns=@JoinColumn(name="person_id",referencedColumnName="person_id") ,inverseJoinColumns=@JoinColumn(name="owner_person_id") ) @MapKey(columns=@Column(name="owner_type_cd"),targetElement=ChargebackOwnerType.class) @Enumerated(EnumType.STRING) @Sort(type=SortType.NATURAL) private SortedMap<ChargebackOwnerType,Person> owners = new TreeMap<ChargebackOwnerType, Person>(); -- 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

14 years, 9 months

3
5
0 / 0

[Hibernate-JIRA] Created: (HHH-2449) Lazy loading for one-to-one asociations

by jose (JIRA)

Lazy loading for one-to-one asociations --------------------------------------- Key: HHH-2449 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2449 Project: Hibernate3 Type: New Feature Components: core Versions: 3.2.2 Environment: Hibernate 3.2.2 Reporter: jose After read "Some explanations on lazy loading" and my tests I found a lossing feature in Hibernate (3.2.2). one-to-one with lazy="proxy"_____________________________________________ Hibernate ALWAYS launch selects to know if one-to-one is null or can be proxied. one-to-one with lazy="no-proxy"__________________________________________ Instrumentation allows to hibernate modify the getter to allows lazy loading on demand: * but allways initialize ALL no-proxy relations (with first getter call) -> must initialize ONLY the requested property * never auto-initialize FETCH joins, ALWAYS doit on demand (if opened session) -> must auto-initialize ONLY the FETCHED property note: Can submit a fix for this? How? NEW FEATURE: one-to-one with lazy="proxy" without multiple SELECTS______ If Hibernate adds join, for all one-to-one relations, to get the foreign-key of other tables, can check it to create a proxy or null. note: that hibernate adds joins for hierarchy, why not for one-to-one relations? This solution avoids: * 'multiple subselects' after first select * 'instrumentation' of bytecode -- 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

14 years, 9 months

3
2
0 / 0

[Hibernate-JIRA] Created: (ANN-614) @WhereJoinTable doesn't work with @ManyToOne

by Victor (JIRA)

@WhereJoinTable doesn't work with @ManyToOne -------------------------------------------- Key: ANN-614 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-614 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.3.0.ga Reporter: Victor @ManyToOne( fetch=FetchType.LAZY ) @JoinTable(name="CATEGORY_PRODUCT", uniqueConstraints = @UniqueConstraint(columnNames = {"PDID", "CATID"}), joinColumns = @JoinColumn(name="PDID"), inverseJoinColumns = @JoinColumn(name="CATID") ) @WhereJoinTable(clause="CATMAIN=1") protected Category getMainCategory() { return mainCategory; } protected void setMainCategories(Category mainCategory) { this.mainCategory = mainCategory; } Best regards, Victor -- 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

14 years, 9 months

5
5
0 / 0

[Hibernate-JIRA] Created: (HHH-4648) Mapping exception when one class maps to multiple tables.

by Subhan (JIRA)

Mapping exception when one class maps to multiple tables. --------------------------------------------------------- Key: HHH-4648 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4648 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.5.0-Beta-2 Environment: hibernate-envers-3.5.0-Beta-2 and hibernate-core-3.3.2.GA Reporter: Subhan Priority: Critical The problem arises when there is one class mapped to multiple tables separated by entity name. See the scenarios about it here: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=164631. -- 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

14 years, 9 months

4
5
0 / 0

[Hibernate-JIRA] Created: (HHH-3029) use_sql_commants fails on Derby

by Oleksandr Alesinskyy (JIRA)

use_sql_commants fails on Derby ------------------------------- Key: HHH-3029 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3029 Project: Hibernate3 Issue Type: Bug Environment: WinXP, SP2 Java 1.5..0_12, Spring 2.0.7, Hibernate 3.2.5ga, Derby 10.3.2.1 Reporter: Oleksandr Alesinskyy Activation is use_sql_comments cause SQL exception /* insert de.ntec.lms.impl.P1Bean */ insert into P1 (VERSION, CELL_POS, CODE, CELL_ID, PLACE_ID) values (?, ?, ?, ?, ?) 2007-12-25 11:46:29,406 WARN org.hibernate.util.JDBCExceptionReporter SQL Error: -1, SQLState: 42X01 2007-12-25 11:46:29,406 ERROR org.hibernate.util.JDBCExceptionReporter Syntaxfehler: Encountered "/" at line 1, column 1. 2007-12-25 11:46:29,487 ERROR org.hibernate.event.def.AbstractFlushingEventListener Could not synchronize database state with session org.hibernate.exception.SQLGrammarException: could not insert: [de.ntec.lms.impl.P1Bean] at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:67) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2078) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2427) at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:51) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:248) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:232) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:139) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:297) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:985) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:333) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106) at de.ntec.lms.impl.PerformanceTest.doMain(PerformanceTest.java:84) at de.ntec.lms.impl.PerformanceTest.main(PerformanceTest.java:46) Caused by: java.sql.SQLException: Syntaxfehler: Encountered "/" at line 1, column 1. at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.client.am.Connection.prepareStatement(Unknown Source) at org.apache.commons.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:185) at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.prepareStatement(PoolingDataSource.java:278) at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:442) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:93) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:86) at org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:171) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2048) ... 12 more Caused by: org.apache.derby.client.am.SqlException: Syntaxfehler: Encountered "/" at line 1, column 1. at org.apache.derby.client.am.Statement.completeSqlca(Unknown Source) at org.apache.derby.client.net.NetStatementReply.parsePrepareError(Unknown Source) at org.apache.derby.client.net.NetStatementReply.parsePRPSQLSTTreply(Unknown Source) at org.apache.derby.client.net.NetStatementReply.readPrepareDescribeOutput(Unknown Source) at org.apache.derby.client.net.StatementReply.readPrepareDescribeOutput(Unknown Source) at org.apache.derby.client.net.NetStatement.readPrepareDescribeOutput_(Unknown Source) at org.apache.derby.client.am.Statement.readPrepareDescribeOutput(Unknown Source) at org.apache.derby.client.am.PreparedStatement.readPrepareDescribeInputOutput(Unknown Source) at org.apache.derby.client.am.PreparedStatement.flowPrepareDescribeInputOutput(Unknown Source) at org.apache.derby.client.am.PreparedStatement.prepare(Unknown Source) at org.apache.derby.client.am.Connection.prepareStatementX(Unknown Source) ... 20 more Hibernate settings (via Spring) <property name="manglableMappingResources"> <list> <value>de/ntec/lms/impl/P1Bean.hbm.xml</value> </list> </property> <property name="hibernateProperties"> <props> <prop key="hibernate.dialect">org.hibernate.dialect.DerbyDialect</prop> <prop key="hibernate.show_sql">true</prop> <prop key="hibernate.format_sql">true</prop> <prop key="hibernate.use_sql_comments">true</prop> <prop key="hibernate.cglib.use_reflection_optimizer">false</prop> </props> </property> When use_sql_comments is false all works smoothly. Failing code P1Bean p1= new P1Bean(); p1.setCell(1); p1.setCellPosition(2); p1.setCode("A"); s.save(p1); -- 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

14 years, 9 months

3
13
0 / 0

[Hibernate-JIRA] Created: (HHH-5002) testQuery in org.hibernate.test.legacy.FooBarTest errors running with Ingres dialect

by Ray Fan (JIRA)

testQuery in org.hibernate.test.legacy.FooBarTest errors running with Ingres dialect ------------------------------------------------------------------------------------ Key: HHH-5002 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5002 Project: Hibernate Core Issue Type: Bug Components: query-sql, testsuite Affects Versions: 3.5.0-CR-2 Environment: Hibernate 3.5.0-CR-2, Ingres 9.3.1 (int.lnx/106), IngresDialect Reporter: Ray Fan Attachments: legacy.FooBarTest.zip testQuery in org.hibernate.test.legacy.FooBarTest errors with an exception whilst using IngresDialect {noformat} <error message="could not execute query" type="org.hibernate.exception.GenericJDBCException">org.hibernate.exception.GenericJDBCException: could not execute query at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:140) at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:128) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66) at org.hibernate.loader.Loader.doList(Loader.java:2276) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2151) at org.hibernate.loader.Loader.list(Loader.java:2146) at org.hibernate.hql.classic.QueryTranslatorImpl.list(QueryTranslatorImpl.java:936) at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:196) at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1258) at org.hibernate.impl.QueryImpl.list(QueryImpl.java:102) at org.hibernate.test.legacy.FooBarTest.testQuery(FooBarTest.java:388) Caused by: com.ingres.gcf.util.SqlEx: An internal error prevents further processing of this query. Associated error messages which provide more detailed information about the problem can be found in the error log, II_CONFIG:errlog.log at com.ingres.gcf.jdbc.DrvObj.readError(Unknown Source) at com.ingres.gcf.jdbc.DrvObj.readResults(Unknown Source) at com.ingres.gcf.jdbc.RsltFtch.preLoad(Unknown Source) at com.ingres.gcf.jdbc.RsltCurs.preLoad(Unknown Source) at com.ingres.gcf.jdbc.RsltCurs.<init>(Unknown Source) at com.ingres.gcf.jdbc.JdbcPrep.exec(Unknown Source) at com.ingres.gcf.jdbc.JdbcPrep.executeQuery(Unknown Source) at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:208) at org.hibernate.loader.Loader.getResultSet(Loader.java:1832) at org.hibernate.loader.Loader.doQuery(Loader.java:719) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:271) at org.hibernate.loader.Loader.doList(Loader.java:2273) ... 37 more </error> {noformat} -- 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

14 years, 9 months

2
9
0 / 0

[Hibernate-JIRA] Created: (HHH-2646) Informix 10 dialect with BLOB/CLOB support

by Thomas Much (JIRA)

Informix 10 dialect with BLOB/CLOB support ------------------------------------------ Key: HHH-2646 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2646 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.2.4.sp1 Environment: Informix 10 Reporter: Thomas Much Priority: Minor We discovered that Informix 10 works well with mapping types "blob" and "clob" if we use our own dialect that's simply derived from the existing Informix dialect by adding the two missing types: public class Informix10Dialect extends InformixDialect { public Informix10Dialect() { super(); registerColumnType( Types.BLOB, "blob" ); registerColumnType( Types.CLOB, "clob" ); } } We suggest adding this new dialect to Hibernate Core. (This is similar to issue HHH-2523, but here "clob" is mapped, too.) -- 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

14 years, 9 months

4
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2059) Section 19.2 of the documentation does not show Ehcache as supporting clusters. It does.

by Greg Luck (JIRA)

Section 19.2 of the documentation does not show Ehcache as supporting clusters. It does. ----------------------------------------------------------------------------------------- Key: HHH-2059 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2059 Project: Hibernate3 Type: Bug Components: documentation Versions: 3.2.0 cr1, 3.2.0.cr2, 3.2.0.cr3, 3.2.0.cr4 Reporter: Greg Luck Priority: Minor Section 19.2 of the documentation does not show Ehcache as supporting clusters. It does. The only reason I am asking for this is that people are confused about it and are asking me questions over at the ehcache project. e.g. see the following email to the list. From: p.perrucci(a)gmail.com Subject: [ehcache-list] Using ehcache as a clustered cache in hibernate3 Date: 6 September 2006 6:29:21 PM GMT+10:00 To: ehcache-list(a)lists.sourceforge.net Hi all, current version of ehcache implements distributed caching but hibernate3 docs says that ehcache is not cluster safe. Anyone know the reason why it's not possible to use ehcache in such a scenario? Thanks Paolo ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642_... ehcache-list mailing list ehcache-list(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ehcache-list -- 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

14 years, 9 months

6
5
0 / 0

[Hibernate-JIRA] Created: (HHH-3112) Upgrade EhCache dependancy to 1.2.4+

by Stevo Slavic (JIRA)

Upgrade EhCache dependancy to 1.2.4+ ------------------------------------ Key: HHH-3112 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3112 Project: Hibernate3 Issue Type: Improvement Components: caching (L2) Affects Versions: 3.2.5 Reporter: Stevo Slavic Priority: Trivial Hibernate is widely used in conjunction with Spring framework. Spring framework as of version 2.0 expects EhCache to be 1.2.4+. When using both EhCache 1.2.4+ and Hibernate 3.2.5.ga as dependency in same maven project but in different sub-projects, older EhCache 1.2.3 (current Hibernate 3.2.5.ga dependency) can overwrite dependency application has for newer EhCache ( http://forum.springframework.org/showthread.php?t=49956 ). If Hibernate would use 1.2.4+ EhCache there would be no need to specify separate EhCache dependency. -- 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

14 years, 9 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-4630) Criteria join on composite identifier generates wrong alias, SQL error

by Chris Wilson (JIRA)

Criteria join on composite identifier generates wrong alias, SQL error ---------------------------------------------------------------------- Key: HHH-4630 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4630 Project: Hibernate Core Issue Type: Patch Components: core Affects Versions: 3.5 Environment: Hibernate trunk from 2009-11-30, Ubuntu 8.04, Sun Java 1.6.0-17, MySQL 5.0.51a-3ubuntu5.4 Reporter: Chris Wilson Attachments: hibernate-invalid-alias-generation.patch Hibernate generates the wrong alias on a Criteria query involving a join on a composite identifier. For example, in the test below without the fix to JoinWalker, it generates this SQL: select this_.role_code as role1_0_1_, this_.is_deleted as is2_0_1_, this_.record_version as record3_0_1_, complexjoi3_.code as code1_0_, complexjoi3_.is_deleted as is2_1_0_, complexjoi3_.record_version as record3_1_0_ from list_action_roles this_ left outer join roles complexjoi3_ on this_.role_code=complexjoi3_.code where this_.is_deleted=? and complexjoi1_.is_deleted=? Which results in this error from the SQL server: Unknown column 'complexjoi1_.is_deleted' in 'where clause' Analysis of the problem: The entity persister class with the composite identifier has a fake property for it, called "_identifierMapper" (see HbmBinder.bindCompositeId() and similarly in Annotations). This property name ends up in the path used by JoinWalker.walkEntityTree() when it calls walkComponentTree(). However that path is used by CriteriaJoinWalker.generateTableAlias() to look up the correct criteria (and hence the alias) from the translator, a CriteriaQueryTranslator. The alias was created in CriteriaQueryTranslator.createCriteriaSQLAliasMap for a Criteria without this extra _identifierMapper path component. So when CriteriaJoinWalker tries to use the path with _identifierMapper to look up the criteria to find the correct alias to use, in generateTableAlias(), it doesn't find one, so it generates a new alias. That new alias no longer matches the one that will be rendered out in the WHERE clause, so the WHERE clause will refer to table names using aliases that are not used anywhere else in the query, and the SQL server will fail to parse the statement. The solution appears to be to exclude "_identifierMapper" components in the alias path when building it. I don't know what other implications that might have, but it seems like an implementation nastiness that shouldn't be exposed. 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

14 years, 9 months

4
7
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-35) Look for log and exception strategy

by Emmanuel Bernard (JIRA)

Look for log and exception strategy ----------------------------------- Key: HSEARCH-35 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-35 Project: Hibernate Search Type: Task Components: mapping, query, engine, directory provider Reporter: Emmanuel Bernard Priority: Minor Fix For: 3.0.0.beta2 -- 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

14 years, 10 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-210) Support hbm xml mapping!

by Mark Stewart (JIRA)

Support hbm xml mapping! ------------------------ Key: HSEARCH-210 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-210 Project: Hibernate Search Issue Type: Bug Components: mapping Affects Versions: 3.0.1.GA Environment: All. Reporter: Mark Stewart I like annotations as much as the next guy but it's a complete non-starter for our business (and, I suspect, plenty of others) to add full text search to our existing apps via Hibernate Search if it means we must convert all our existing hbm.xml configurations into annotations. The regression testing alone would kill us. The Hibernate project has always been supremely pragmatic which is why I've filed this as a bug rather than a feature request. I don't think Hibernate would have been half as popular if it didn't support things like direct SQL and reverse engineering tools. I think Search would see a big boost if it could be easily added to existing applications. Please consider adding the needed syntax for xml mapping. At the very least an entry in the FAQ that explains the lacking is needed. -- 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

14 years, 10 months

6
11
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-373) @AnalyzerDiscriminator applied to _hibernate_class field

by Sanne Grinovero (JIRA)

@AnalyzerDiscriminator applied to _hibernate_class field -------------------------------------------------------- Key: HSEARCH-373 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-373 Project: Hibernate Search Issue Type: Bug Reporter: Sanne Grinovero It appears that implementations of org.hibernate.search.analyzer.Discriminator is also called to identify the Analyzer to be used to index the reserved "id" and "_hibernate_class". I'm not sure if it's a good idea on "id", it probably isn't at all on "_hibernate_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

14 years, 10 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-264) Make a Luke version that can reuse Hibernate Search analyzers (per entity or per name)

by Emmanuel Bernard (JIRA)

Make a Luke version that can reuse Hibernate Search analyzers (per entity or per name) -------------------------------------------------------------------------------------- Key: HSEARCH-264 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-264 Project: Hibernate Search Issue Type: New Feature Components: query Reporter: Emmanuel Bernard Probably more on Hibernate Tools. Would be nice to fix copy/paste bugs too. -- 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

14 years, 10 months

2
1
0 / 0

[Hibernate-JIRA] Created: (ANN-777) Map key column is included in the PK but is not forced not-null

by Emmanuel Bernard (JIRA)

Map key column is included in the PK but is not forced not-null --------------------------------------------------------------- Key: ANN-777 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-777 Project: Hibernate Annotations Issue Type: Bug Components: binder Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik I think forcing not-null is the right approach. This needs some investigation though -- 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

14 years, 10 months

4
4
0 / 0

[Hibernate-JIRA] Created: (HHH-3031) Include "FOR READ ONLY" hint in non-locking DB2 statements

by Steve Finch (JIRA)

Include "FOR READ ONLY" hint in non-locking DB2 statements ---------------------------------------------------------- Key: HHH-3031 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3031 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.2.5 Environment: 3.2.5, DB2/UDB 8.1+ Reporter: Steve Finch As per the DB2 documentation: http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.i... The FOR READ ONLY clause indicates that the result table is read-only and therefore the cursor cannot be referred to in Positioned UPDATE and DELETE statements. FOR FETCH ONLY has the same meaning. For result tables in which updates and deletes are allowed, specifying FOR READ ONLY (or FOR FETCH ONLY) can possibly improve the performance of FETCH operations by allowing the database manager to do blocking. For example, in programs that contain dynamic SQL statements without the FOR READ ONLY or ORDER BY clause, the database manager might open cursors as if the FOR UPDATE clause were specified. It is recommended, therefore, that the FOR READ ONLY clause be used to improve performance, except in cases where queries will be used in positioned UPDATE or DELETE statements. A read-only result table must not be referred to in a Positioned UPDATE or DELETE statement, whether it is read-only by nature or specified as FOR READ ONLY (FOR FETCH ONLY). The aforementioned improvement can be achieved by applying "FOR READ ONLY" when other locking hints are not specified. Patch to be uploaded soon. -- 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

14 years, 10 months

5
7
0 / 0

[Hibernate-JIRA] Created: (HHH-4975) ManyToOne and referencedColumnName and MappedSuperclass (2 Levels) => org.hibernate.AnnotationException: referencedColumnNames ... not mapped to a single property

by Christian Fritschi (JIRA)

ManyToOne and referencedColumnName and MappedSuperclass (2 Levels) => org.hibernate.AnnotationException: referencedColumnNames ... not mapped to a single property ------------------------------------------------------------------------------------------------------------------------------------------------------------------ Key: HHH-4975 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4975 Project: Hibernate Core Issue Type: Bug Components: annotations Affects Versions: 3.3.2 Environment: Hibernate version 3.3.2.GA, HSQLDB 1.8.0.10 Reporter: Christian Fritschi Priority: Critical Attachments: startTestDb.rar, ukMapping.rar, UkMappingTest.java Level 1 (superClass) ------- @MappedSuperclass public abstract class AbstractMasterUk ... @Id private int id; .... @Column(name="MASTER_ID", nullable = false, length=50) private String masterId; Level 2 (superClass) ------- @Entity @Inheritance(strategy=InheritanceType.SINGLE_TABLE) @Table(name="MASTER_UK") @DiscriminatorColumn(name="DOMAIN", discriminatorType=DiscriminatorType.STRING) public class MasterUkBase extends AbstractMasterUk .... Parent-Class ------------ @Entity @org.hibernate.annotations.Entity(mutable = false) @DiscriminatorValue(MasterUk1.DOMAIN) public class MasterUk1 extends MasterUkBase ... Child-Class ----------- @Entity @Table(name="DETAIL_UK") public class DetailUk implements Serializable { @Id private int id; @ManyToOne(optional=false) @JoinColumn(name="MASTER", nullable=true, referencedColumnName="MASTER_ID") private MasterUk1 master; Result: org.hibernate.AnnotationException: referencedColumnNames(MASTER_ID) of annotations.playground.delta.ukMapping.DetailUk.master referencing annotations.playground.delta.ukMapping.MasterUk1 not mapped to a single property at org.hibernate.cfg.BinderHelper.createSyntheticPropertyReference(BinderHelper.java:180) at org.hibernate.cfg.ToOneFkSecondPass.doSecondPass(ToOneFkSecondPass.java:88) at org.hibernate.cfg.AnnotationConfiguration.processEndOfQueue(AnnotationConfiguration.java:456) at org.hibernate.cfg.AnnotationConfiguration.processFkSecondPassInOrder(AnnotationConfiguration.java:438) at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:309) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1333) at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:867) ..... -- 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

14 years, 10 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3495) CollectionAction instances can consume considerable memory in large transactions unnecessarily

by Tim Downey (JIRA)

CollectionAction instances can consume considerable memory in large transactions unnecessarily ---------------------------------------------------------------------------------------------- Key: HHH-3495 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3495 Project: Hibernate Core Issue Type: Improvement Reporter: Tim Downey Attachments: CollectionActionPatch.zip Hi, We're doing some fairly heavy duty batch processing using Hibernate 3.3.1. In doing so, we're basically paging over large chunks of entities where we flush and clear the session around pages. We do not commit between pages. We may be processing hundreds of thousands of entities over pages of ten to twenty thousand each. We're clearing the session around pages in attempt to free up memory that is no longer necessary. We have found that subtypes of CollectionAction get added to a list of Executable in the ActionQueue when there are collection changes processed. These CollectionActions are held until transaction complete and are not released on flush or clear of the session. Furthermore, the CollectionAction instances hold references to those collections that have changed even after the entities have been evicted from the session. In our case, this was causing Hibernation to hold on to several hundred MB of RAM until transaction commit. I've supplied a small patch that doesn't require the CollectionAction to hang on to the entities themselves until the transaction boundary. We're showing considerably improvement in memory utilization as a result. I'm hoping that you consider this patch for inclusion in a future release. The change was basically to change the ActionQueue's list of Executables used in after transaction completion, to a separate type, AfterTransactionCompletionExecutable. This new type allows some decoupling in the other subclasses of Executable to hold references to fewer resources and save considerable memory when the transaction sizes are quite large. Regards, Tim -- 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

14 years, 10 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2169) L2 Cache and Long transactions Memory Leak : OutOfMemoryException

by Sami Dalouche (JIRA)

L2 Cache and Long transactions Memory Leak : OutOfMemoryException ----------------------------------------------------------------- Key: HHH-2169 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2169 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.ga Environment: [b]Hibernate version:[/b] Hibernate Entity Manager 3.2.0, with Hibernate Core 3.2.0 and Hibernate Annotations 3.2.0 [b]Mapping documents:[/b] Annotations [b]Full stack trace of any exception that occurs:[/b] Memory Heap Exception [b]Name and version of the database you are using:[/b] PosgreSQL 8.1 Reporter: Sami Dalouche Summary --------- When enabling L2 Cache (with either OScache and EhCache, both with a limitation on the max #of instances, so the problem shouldn't come from the cache manager), Hibernate cannot have long running transactions, otherwise, it results in a Memory Heap Exception... The problem does NOT happen if the L2 Cache is disabled ! Details ---------- - Configure the code to run in ONE transaction - Have a huge loop that inserts 2 million entries that are cacheable (@Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)) - flush() and clear() every 1000 entries, to periodically flush the cache => None of the entries are garbage collected. => Using a profiler, it is possible to trace the owning objects of my domain classes to : - org.hibernate.action.EntityInsertAction ("instance" variable) - array / List (variable elementData) - variable "executions" in object .. class org.hibernate.engine.ActionQueue Remarks : - If the Query Cache is disabled, and the objects being inserted are NOT cacheable (no @Cache annotation), there is no problem - If the Query Cache is enabled, then, no matter whether the objects being inserted are cacheable or not, The entries are never garbage collected, and I get an OutOfMemoryException. (I see NO relationship between the Query Cache and my objects. I never query the objects, only save them !!) -- 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

14 years, 10 months

5
8
0 / 0

[Hibernate-JIRA] Created: (HHH-3195) session.clear() is not effective when use_query_cache is true

by James Berry (JIRA)

session.clear() is not effective when use_query_cache is true ------------------------------------------------------------- Key: HHH-3195 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3195 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.6 Environment: 3.2.6.ga, MySQL5 Reporter: James Berry As discussed in detail in http://forum.hibernate.org/viewtopic.php?t=944918, performing many inserts while use_query_cache is enabled will eventually cause an out of memory condition, even if the session is periodically flushed and cleared. That forum thread describes a potential root cause for this problem. Nobody from the Hibernate team has responded regarding the forum thread, even though it's been alive for three years now! Note that an answer to "disable the query cache" is not a good solution to the problem, as we need the query cache elsewhere. If it were possible to disable the query cache for a particular session, that would be fine, but I see no way do that. -- 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

14 years, 10 months

7
9
0 / 0

[Hibernate-JIRA] Created: (HV-315) Create package-level JavaDoc for the AP

by Gunnar Morling (JIRA)

Create package-level JavaDoc for the AP --------------------------------------- Key: HV-315 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-315 Project: Hibernate Validator Issue Type: Improvement Components: annotation-processor Affects Versions: 4.1.0.Beta1 Reporter: Gunnar Morling Assignee: Hardy Ferentschik Priority: Minor Fix For: 4.1.0 Currently there are no package-level JavaDocs for the AP. These should be added. The top-level doc should contain an overview over the APs architecture in general. -- 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

14 years, 10 months

4
6
0 / 0

[Hibernate-JIRA] Created: (HHH-2735) Query . setLockMode cannot find the alias when the query defines a select clause

by Tamir Solomon (JIRA)

Query . setLockMode cannot find the alias when the query defines a select clause -------------------------------------------------------------------------------- Key: HHH-2735 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2735 Project: Hibernate3 Issue Type: Bug Reporter: Tamir Solomon I tried to perform the following : Query q1 = session.createQuery("select serverIP.server from ServerIP serverIP where serverIP.ip = :ipStr"); q1.setLockMode("serverIP",LockMode.NONE); q1.setParameter("ipStr", ip); q1.list(); and i get this error : Frame : java.lang.IllegalArgumentException: alias not found: serverIP at org.hibernate.loader.hql.QueryLoader.applyLocks(QueryLoader.java:299) at org.hibernate.loader.Loader.preprocessSQL(Loader.java:189) at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1529) at org.hibernate.loader.Loader.doQuery(Loader.java:661) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224) at org.hibernate.loader.Loader.doList(Loader.java:2211) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2095) at org.hibernate.loader.Loader.list(Loader.java:2090) at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:388) at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:338) at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172) at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121) at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79) -- 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

14 years, 10 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4582) Repeated column in mapping for entity in composite id

by Franck Bisti (JIRA)

Repeated column in mapping for entity in composite id ----------------------------------------------------- Key: HHH-4582 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4582 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Environment: Hibernate 3.3.1 Reporter: Franck Bisti Priority: Minor Attachments: PersistentClass.java I have a composite-id with 2 manytoone. The two manytoone are composed by 3 columns each. They share 2 columns. @Embeddable public class FooBarId implements Serializable { @ManyToOne() @JoinColumns({ @JoinColumn(name="FOO_BAR1", referencedColumnName="FOO_BAR1",nullable=false, updatable=true, insertable=true), @JoinColumn(name="FOO_BAR2", referencedColumnName="FOO_BAR2",nullable=false, updatable=true, insertable=true), @JoinColumn(name="FOO_ID", referencedColumnName="ID",nullable=false, updatable=true, insertable=true) }) private Foo foo; /** Attribute*/ @ManyToOne() @JoinColumns({ @JoinColumn(name="FOO_BAR1", referencedColumnName="FOO_BAR1",nullable=false, updatable=false, insertable=false), @JoinColumn(name="FOO_BAR2", referencedColumnName="FOO_BAR2",nullable=false, updatable=false, insertable=false), @JoinColumn(name="BAR_ID", referencedColumnName="ID",nullable=false, updatable=false, insertable=false) }) private Bar bar; Exception : Caused by: org.hibernate.MappingException: Repeated column in mapping for entity: com.test.FooBar column: FOO_BAR2 (should be mapped with insert="false" update="false") at org.hibernate.mapping.PersistentClass.checkColumnDuplication(PersistentClass.java:670) at org.hibernate.mapping.PersistentClass.checkColumnDuplication(PersistentClass.java:711) at org.hibernate.mapping.PersistentClass.validate(PersistentClass.java:468) at org.hibernate.mapping.RootClass.validate(RootClass.java:215) at org.hibernate.cfg.Configuration.validate(Configuration.java:1135) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1320) at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:854) at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:669) I have the "Repeated column in mapping" exception because Hibernate doesn't use the insertable and updtable property in the PersistentClass.checkColumnDuplication for composite-id. I have modified the PersistentClass.checkColumnDuplication() by use of getColumnUpdateability code and it seems to works fine (see attached file) I don't know if that can help -- 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

14 years, 10 months

4
7
0 / 0

[Hibernate-JIRA] Created: (HHH-3361) LazyInitializationException generate an error message in the logs

by benoit heinrich (JIRA)

LazyInitializationException generate an error message in the logs ----------------------------------------------------------------- Key: HHH-3361 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3361 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.3.0.CR1 Reporter: benoit heinrich Priority: Minor Hi, When a LazyInitializationException is thrown a log message is automatically created by the exception class because of the line 19 in the LIE class: LoggerFactory.getLogger( LazyInitializationException.class ).error( msg, this ); An exception should not write log messages, this is part of the application that handle the exception that should decide either or nor a log message should be created. The exception should just carry all information with it and no more. Actually this is causing a serious problem to one of the application I'm working on because LIE is a normal exception and is caught and handled correctly and each time a LIE is thrown by hibernate I'm getting a full stack trace in the logs (which is wrong in my case because the exception is handled correctly). Also I don't want to change the log4j settings to ignore the LIE because I'd like to know when I get a LIE that is not caught. So my suggestion is to simply remove the Log entry from the LIE constructor since normally this message is anyway redundant because if the exception is not caught the application will dump the exception in most of the time. Cheers, /Benoit -- 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

14 years, 10 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2141) problem with JavaAssist

by Ramil Israfilov (JIRA)

problem with JavaAssist ------------------------ Key: HHH-2141 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2141 Project: Hibernate3 Type: Bug Versions: 3.2.0.cr2 Reporter: Ramil Israfilov I have an Java interface: public interface Credentials { public long getId(); public void setId(long id); Object getCredentialsForProtocol(String protocol) throws ProtocolException; } and implementation class: ------- public class BasicCredentials implements Serializable, Credentials { private long id; private String username; private String password; private static final Log log = LogFactory.getLog(BasicCredentials.class); public BasicCredentials() { super(); } public BasicCredentials(String username, String password) { super(); this.username = username; this.password = password; } /** * @return Returns the password. */ public String getPassword() { return password; } /** * @param password * The password to set. */ public void setPassword(String password) { this.password = password; } /** * @return Returns the username. */ public String getUsername() { return username; } /** * @param username * The username to set. */ public void setUsername(String username) { this.username = username; } public Object getCredentialsForProtocol(String protocol) { if (protocol != null && protocol.equalsIgnoreCase("HTTP")) { return new UsernamePasswordCredentials(username, password); } log.error("Unsupported protoco:" + protocol); return null; } public long getId() { return id; } public void setId(long id) { this.id = id; } ---- Also I have an Credentials.hbm.xml file: <hibernate-mapping package="be.certipost.comms.accessclient"> <class name="Credentials" table="COMMS$CREDENTIALS"> <id name="id" type="long" unsaved-value="0"> <generator class="native"/> </id> <discriminator column="CREDENTIALS_TYPE" type="string"/> <subclass name="BasicCredentials" discriminator-value="BC"> <property name="username" lazy="false" generated="never" type="string"></property> <property name="password" lazy="false" generated="never" type="string"></property> </subclass> </class> </hibernate-mapping> I have deployed those claases and mapping to JBOSS 4.0.4GA: I construct EAR file which contains inside JAR file with my classes and hbm file. And during deploying I got error: 2006-10-12 10:37:32,350 INFO [org.hibernate.cfg.Environment] Hibernate 3.2 cr2 2006-10-12 10:37:32,365 INFO [org.hibernate.cfg.Environment] hibernate.properties not found 2006-10-12 10:37:32,381 INFO [org.hibernate.cfg.Environment] Bytecode provider name : javassist 2006-10-12 10:37:32,381 INFO [org.hibernate.cfg.Environment] using JDK 1.4 java.sql.Timestamp handling 2006-10-12 10:37:32,506 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: commons-lang-2.1.jar 2006-10-12 10:37:32,506 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: datatools.jar 2006-10-12 10:37:32,506 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: ejb3-persistence.jar 2006-10-12 10:37:32,506 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: jsr173_api.jar 2006-10-12 10:37:32,506 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: CertioneCommsClient.jar 2006-10-12 10:37:32,521 INFO [org.hibernate.cfg.Configuration] Found mapping document in jar: be/certipost/comms/DataInstructions.hbm.xml 2006-10-12 10:37:32,771 INFO [org.hibernate.cfg.HbmBinder] Mapping class: be.certipost.comms.DataInstructions -> COMMS$METADATAS 2006-10-12 10:37:32,818 INFO [org.hibernate.cfg.Configuration] Found mapping document in jar: be/certipost/comms/Request.hbm.xml 2006-10-12 10:37:32,943 INFO [org.hibernate.cfg.HbmBinder] Mapping class: be.certipost.comms.Request -> COMMS$REQUESTS 2006-10-12 10:37:32,959 INFO [org.hibernate.cfg.HbmBinder] Mapping collection: be.certipost.comms.Request.acks -> COMMS$REQ_ACKS 2006-10-12 10:37:33,193 INFO [org.hibernate.cfg.Configuration] Found mapping document in jar: be/certipost/comms/Response.hbm.xml 2006-10-12 10:37:33,256 INFO [org.hibernate.cfg.HbmBinder] Mapping class: be.certipost.comms.Response -> COMMS$RESPONSES 2006-10-12 10:37:33,256 INFO [org.hibernate.cfg.HbmBinder] Mapping collection: be.certipost.comms.Response.acks -> COMMS$RESP_ACKS 2006-10-12 10:37:33,256 INFO [org.hibernate.cfg.Configuration] Found mapping document in jar: be/certipost/comms/Session.hbm.xml 2006-10-12 10:37:33,506 INFO [org.hibernate.cfg.HbmBinder] Mapping class: be.certipost.comms.Session -> COMMS$SESSIONS 2006-10-12 10:37:33,506 INFO [org.hibernate.cfg.Configuration] Found mapping document in jar: be/certipost/comms/accessclient/Credentials.hbm.xml 2006-10-12 10:37:33,600 INFO [org.hibernate.cfg.HbmBinder] Mapping class: be.certipost.comms.accessclient.Credentials -> COMMS$CREDENTIALS 2006-10-12 10:37:33,771 INFO [org.hibernate.cfg.HbmBinder] Mapping subclass: be.certipost.comms.accessclient.BasicCredentials -> COMMS$CREDENTIALS 2006-10-12 10:37:33,771 INFO [org.hibernate.cfg.Configuration] Found mapping document in jar: be/certipost/comms/accessclient/config/ClientProperties.hbm.xml 2006-10-12 10:37:33,818 INFO [org.hibernate.cfg.HbmBinder] Mapping class: be.certipost.comms.accessclient.config.ClientProperties -> COMMS$CLIENTPROPERTIES 2006-10-12 10:37:33,818 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: hibernate-annotations.jar 2006-10-12 10:37:33,834 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: quartz-all-1.5.2.jar 2006-10-12 10:37:33,834 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: jaxb-impl.jar 2006-10-12 10:37:33,850 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: jaxb-api.jar 2006-10-12 10:37:33,850 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: activation.jar 2006-10-12 10:37:33,865 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: commons-httpclient-3.0.1.jar 2006-10-12 10:37:33,865 INFO [org.hibernate.cfg.Configuration] Searching for mapping documents in jar: tmp38363CertioneCommsClient.ear 2006-10-12 10:37:33,865 INFO [org.hibernate.cfg.HbmBinder] Mapping collection: be.certipost.comms.Session.requests -> COMMS$REQUESTS 2006-10-12 10:37:33,959 INFO [org.hibernate.util.NamingHelper] JNDI InitialContext properties:{} 2006-10-12 10:37:33,959 INFO [org.hibernate.connection.DatasourceConnectionProvider] Using datasource: java:/CertioneCommsDS 2006-10-12 10:37:33,975 INFO [org.hibernate.cfg.SettingsFactory] RDBMS: HSQL Database Engine, version: 1.8.0 2006-10-12 10:37:33,975 INFO [org.hibernate.cfg.SettingsFactory] JDBC driver: HSQL Database Engine Driver, version: 1.8.0 2006-10-12 10:37:34,021 INFO [org.hibernate.dialect.Dialect] Using dialect: org.hibernate.dialect.HSQLDialect 2006-10-12 10:37:34,021 INFO [org.hibernate.transaction.TransactionFactoryFactory] Transaction strategy: org.hibernate.transaction.JTATransactionFactory 2006-10-12 10:37:34,037 INFO [org.hibernate.util.NamingHelper] JNDI InitialContext properties:{} 2006-10-12 10:37:34,037 INFO [org.hibernate.transaction.TransactionManagerLookupFactory] instantiating TransactionManagerLookup: org.hibernate.transaction.JBossTransactionManagerLookup 2006-10-12 10:37:34,037 INFO [org.hibernate.transaction.TransactionManagerLookupFactory] instantiated TransactionManagerLookup 2006-10-12 10:37:34,037 INFO [org.hibernate.transaction.TransactionManagerLookupFactory] instantiating TransactionManagerLookup: org.hibernate.transaction.JBossTransactionManagerLookup 2006-10-12 10:37:34,037 INFO [org.hibernate.transaction.TransactionManagerLookupFactory] instantiated TransactionManagerLookup 2006-10-12 10:37:34,037 INFO [org.hibernate.cfg.SettingsFactory] Automatic flush during beforeCompletion(): enabled 2006-10-12 10:37:34,037 INFO [org.hibernate.cfg.SettingsFactory] Automatic session close at end of transaction: enabled 2006-10-12 10:37:34,037 INFO [org.hibernate.cfg.SettingsFactory] JDBC batch size: 15 2006-10-12 10:37:34,037 INFO [org.hibernate.cfg.SettingsFactory] JDBC batch updates for versioned data: enabled 2006-10-12 10:37:34,037 INFO [org.hibernate.cfg.SettingsFactory] Scrollable result sets: enabled 2006-10-12 10:37:34,037 INFO [org.hibernate.cfg.SettingsFactory] JDBC3 getGeneratedKeys(): disabled 2006-10-12 10:37:34,037 INFO [org.hibernate.cfg.SettingsFactory] Connection release mode: after_statement 2006-10-12 10:37:34,037 INFO [org.hibernate.cfg.SettingsFactory] Maximum outer join fetch depth: 5 2006-10-12 10:37:34,053 INFO [org.hibernate.cfg.SettingsFactory] Default batch fetch size: 1 2006-10-12 10:37:34,053 INFO [org.hibernate.cfg.SettingsFactory] Generate SQL with comments: disabled 2006-10-12 10:37:34,053 INFO [org.hibernate.cfg.SettingsFactory] Order SQL updates by primary key: disabled 2006-10-12 10:37:34,053 INFO [org.hibernate.cfg.SettingsFactory] Query translator: org.hibernate.hql.ast.ASTQueryTranslatorFactory 2006-10-12 10:37:34,053 INFO [org.hibernate.hql.ast.ASTQueryTranslatorFactory] Using ASTQueryTranslatorFactory 2006-10-12 10:37:34,053 INFO [org.hibernate.cfg.SettingsFactory] Query language substitutions: {} 2006-10-12 10:37:34,053 INFO [org.hibernate.cfg.SettingsFactory] Second-level cache: enabled 2006-10-12 10:37:34,053 INFO [org.hibernate.cfg.SettingsFactory] Query cache: enabled 2006-10-12 10:37:34,053 INFO [org.hibernate.cfg.SettingsFactory] Cache provider: org.hibernate.cache.HashtableCacheProvider 2006-10-12 10:37:34,053 INFO [org.hibernate.cfg.SettingsFactory] Optimize cache for minimal puts: disabled 2006-10-12 10:37:34,053 INFO [org.hibernate.cfg.SettingsFactory] Structured second-level cache entries: disabled 2006-10-12 10:37:34,053 INFO [org.hibernate.cfg.SettingsFactory] Query cache factory: org.hibernate.cache.StandardQueryCacheFactory 2006-10-12 10:37:34,068 INFO [org.hibernate.cfg.SettingsFactory] Statistics: disabled 2006-10-12 10:37:34,084 INFO [org.hibernate.cfg.SettingsFactory] Deleted entity synthetic identifier rollback: disabled 2006-10-12 10:37:34,084 INFO [org.hibernate.cfg.SettingsFactory] Default entity-mode: pojo 2006-10-12 10:37:34,131 INFO [org.hibernate.impl.SessionFactoryImpl] building session factory 2006-10-12 10:37:34,506 ERROR [org.hibernate.proxy.pojo.BasicLazyInitializer] Javassist Enhancement failed: be.certipost.comms.accessclient.Credentials java.lang.RuntimeException: by java.lang.NoClassDefFoundError: be/certipost/comms/accessclient/Credentials at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:174) at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxyFactory(JavassistLazyInitializer.java:141) at org.hibernate.proxy.pojo.javassist.JavassistProxyFactory.postInstantiate(JavassistProxyFactory.java:42) at org.hibernate.tuple.PojoEntityTuplizer.buildProxyFactory(PojoEntityTuplizer.java:159) at org.hibernate.tuple.AbstractEntityTuplizer.<init>(AbstractEntityTuplizer.java:131) at org.hibernate.tuple.PojoEntityTuplizer.<init>(PojoEntityTuplizer.java:50) at org.hibernate.tuple.TuplizerLookup.create(TuplizerLookup.java:64) at org.hibernate.tuple.EntityMetamodel.<init>(EntityMetamodel.java:256) at org.hibernate.persister.entity.AbstractEntityPersister.<init>(AbstractEntityPersister.java:418) at org.hibernate.persister.entity.SingleTableEntityPersister.<init>(SingleTableEntityPersister.java:108) at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:55) at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:223) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1213) at org.jboss.hibernate.jmx.Hibernate.buildSessionFactory(Hibernate.java:231) at org.jboss.hibernate.jmx.Hibernate.startService(Hibernate.java:155) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at org.jboss.system.ServiceController.start(ServiceController.java:435) at org.jboss.system.ServiceController.start(ServiceController.java:435) at org.jboss.system.ServiceController.start(ServiceController.java:435) at org.jboss.system.ServiceController.start(ServiceController.java:435) at org.jboss.system.ServiceController.start(ServiceController.java:435) at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy37.start(Unknown Source) at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:997) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771) at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy8.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy5.deploy(Unknown Source) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362) at org.jboss.Main.boot(Main.java:200) at org.jboss.Main$1.run(Main.java:464) at java.lang.Thread.run(Thread.java:595) Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: be/certipost/comms/accessclient/Credentials at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:167) at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:170) ... 126 more Caused by: java.lang.NoClassDefFoundError: be/certipost/comms/accessclient/Credentials at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:159) ... 127 more 2006-10-12 10:37:34,615 WARN [org.hibernate.tuple.PojoEntityTuplizer] could not create proxy factory for:be.certipost.comms.accessclient.Credentials org.hibernate.HibernateException: Javassist Enhancement failed: be.certipost.comms.accessclient.Credentials at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxyFactory(JavassistLazyInitializer.java:149) at org.hibernate.proxy.pojo.javassist.JavassistProxyFactory.postInstantiate(JavassistProxyFactory.java:42) at org.hibernate.tuple.PojoEntityTuplizer.buildProxyFactory(PojoEntityTuplizer.java:159) at org.hibernate.tuple.AbstractEntityTuplizer.<init>(AbstractEntityTuplizer.java:131) at org.hibernate.tuple.PojoEntityTuplizer.<init>(PojoEntityTuplizer.java:50) at org.hibernate.tuple.TuplizerLookup.create(TuplizerLookup.java:64) at org.hibernate.tuple.EntityMetamodel.<init>(EntityMetamodel.java:256) at org.hibernate.persister.entity.AbstractEntityPersister.<init>(AbstractEntityPersister.java:418) at org.hibernate.persister.entity.SingleTableEntityPersister.<init>(SingleTableEntityPersister.java:108) at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:55) at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:223) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1213) at org.jboss.hibernate.jmx.Hibernate.buildSessionFactory(Hibernate.java:231) at org.jboss.hibernate.jmx.Hibernate.startService(Hibernate.java:155) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at org.jboss.system.ServiceController.start(ServiceController.java:435) at org.jboss.system.ServiceController.start(ServiceController.java:435) at org.jboss.system.ServiceController.start(ServiceController.java:435) at org.jboss.system.ServiceController.start(ServiceController.java:435) at org.jboss.system.ServiceController.start(ServiceController.java:435) at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy37.start(Unknown Source) at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:997) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771) at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy8.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy5.deploy(Unknown Source) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362) at org.jboss.Main.boot(Main.java:200) at org.jboss.Main$1.run(Main.java:464) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.RuntimeException: by java.lang.NoClassDefFoundError: be/certipost/comms/accessclient/Credentials at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:174) at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxyFactory(JavassistLazyInitializer.java:141) ... 125 more Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: be/certipost/comms/accessclient/Credentials at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:167) at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:170) ... 126 more Caused by: java.lang.NoClassDefFoundError: be/certipost/comms/accessclient/Credentials at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:159) ... 127 more Strange thing that tables are created and credentials objects persisted correctly. It is starnge that I got ERROR in log files. -- 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

14 years, 10 months

4
7
0 / 0

[Hibernate-JIRA] Created: (HHH-3344) DB2Dialect.getLimitString doesn't work for some queries

by Damon Horrell (JIRA)

DB2Dialect.getLimitString doesn't work for some queries ------------------------------------------------------- Key: HHH-3344 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3344 Project: Hibernate3 Issue Type: Bug Reporter: Damon Horrell Priority: Minor If a query uses * but doesn't use a table alias then the modified query created by DB2Dialect.getLimitString is invalid. e.g. select * from mytable becomes select * from ( select rownumber() over() as rownumber_, * from mytable ) as temp_ where rownumber_ <= ? which causes DB2 SQL error: SQLCODE: -104, SQLSTATE: 42601, SQLERRMC: *;ver() as rownumber_,;<select_sublist> I have worked around this for my project by extending DB2Dialect with: public String getLimitString(String sql, boolean hasOffset) { return "select * from ( select rownumber() over() as rownumber_, original_query.* from (" + sql + ") original_query ) as temp_ where rownumber_ <= ?"; } This code will need extending to handle the hasOffset case etc. Real code probably won't be using select * anyway so this probably isn't a big problem. My example allows the user to enter a custom query so I have to handle this situation. -- 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

14 years, 11 months

3
5
0 / 0

[Hibernate-JIRA] Created: (HHH-2176) DB2 setMaxResults problem in Hibernate 3.1.3

by Winter Lau (JIRA)

DB2 setMaxResults problem in Hibernate 3.1.3 -------------------------------------------- Key: HHH-2176 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2176 Project: Hibernate3 Type: Bug Components: core Versions: 3.1.3 Environment: DB2 any version Hibernate 3.1.3 JDK 1.5 Reporter: Winter Lau Priority: Blocker public static List listHotTags(int count){ Session ssn = getSession(); String sql = "SELECT tag_name,COUNT(*) FROM dlog_tag GROUP BY tag_name ORDER BY 2 DESC"; SQLQuery query = ssn.createSQLQuery(sql); query.setMaxResults(count); List tags = new ArrayList(); List results = query.list(); for(int i=0;results!=null && i tags.add(((Object[])results.get(i))[0]); } return tags; } tags.add(((Object[])results.get(i))[0]); this code work fine in other database, but in DB2 , it return the rownumber, i must change to get the second element of array then it return the correct 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

14 years, 11 months

4
12
0 / 0

[Hibernate-JIRA] Created: (HHH-4943) ilike support is incomplete

by James Nobis (JIRA)

ilike support is incomplete --------------------------- Key: HHH-4943 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4943 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.2 Environment: 3.3.2GA MySQL/PostgreSQL Reporter: James Nobis ILIKE is currently supported for PostgreSQL in: hibernate-distribution-3.3.2.GA/project/core/src/main/java/org/hibernate/criterion/IlikeExpression.java: if ( dialect instanceof PostgreSQLDialect ) { return columns[0] + " ilike ?"; } else { return dialect.getLowercaseFunction() + '(' + columns[0] + ") like ?"; } //TODO: get SQL rendering out of this package! 1) This should be in the Dialect 2) PostgreSQL isn't the only DB with ILIKE 3) using instanceof for this is just sloppy 4) this implementation using getLowercaseFunction works with MySQL but fails with DBs like Firebird -- 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

14 years, 11 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HHH-5277) Build fails on some systems when using jdk 6

by Hardy Ferentschik (JIRA)

Build fails on some systems when using jdk 6 -------------------------------------------- Key: HHH-5277 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5277 Project: Hibernate Core Issue Type: Bug Components: build Reporter: Hardy Ferentschik When building Core using Java 6 artifacts are renamed during install from *.jar to *.jdocbook-style (at list in the core sub-module). This of course screws up the local repo. Here is the build log of a _mvn install_ in the core module: {noformat} 517$ setJava 1.6 Configuring Shell Environment for Java 1.6 Current Java: java version "1.6.0_20" Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode) hardy@aleppo:~/work/hibernate/core/trunk/core 518$ mvn clean install -Dmaven.test.skip=true [INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [INFO] Building Hibernate Core [INFO] task-segment: [clean, install] [INFO] ------------------------------------------------------------------------ [INFO] [clean:clean {execution: default-clean}] [INFO] Deleting directory /Users/hardy/work/hibernate/core/trunk/core/target [INFO] [enforcer:enforce {execution: enforce-java}] [INFO] [antlr:generate {execution: default}] [INFO] Using Antlr grammar: /Users/hardy/work/hibernate/core/trunk/core/src/main/antlr/hql.g ANTLR Parser Generator Version 2.7.6 (2005-12-22) 1989-2005 warning: invalid command-line argument: -traceTreeParser; ignored [INFO] Using Antlr grammar: /Users/hardy/work/hibernate/core/trunk/core/src/main/antlr/hql-sql.g ANTLR Parser Generator Version 2.7.6 (2005-12-22) 1989-2005 warning: invalid command-line argument: -traceParser; ignored [INFO] Using Antlr grammar: /Users/hardy/work/hibernate/core/trunk/core/src/main/antlr/sql-gen.g ANTLR Parser Generator Version 2.7.6 (2005-12-22) 1989-2005 warning: invalid command-line argument: -traceParser; ignored [INFO] Using Antlr grammar: /Users/hardy/work/hibernate/core/trunk/core/src/main/antlr/order-by.g ANTLR Parser Generator Version 2.7.6 (2005-12-22) 1989-2005 warning: invalid command-line argument: -traceTreeParser; ignored [INFO] Using Antlr grammar: /Users/hardy/work/hibernate/core/trunk/core/src/main/antlr/order-by-render.g ANTLR Parser Generator Version 2.7.6 (2005-12-22) 1989-2005 warning: invalid command-line argument: -traceParser; ignored [INFO] [resources:resources {execution: default-resources}] [WARNING] Using platform encoding (MacRoman actually) to copy filtered resources, i.e. build is platform dependent! [INFO] Copying 3 resources [INFO] Copying 5 resources [INFO] [compiler:compile {execution: default-compile}] [INFO] Compiling 1306 source files to /Users/hardy/work/hibernate/core/trunk/core/target/classes [INFO] [injection:bytecode {execution: default}] [INFO] writing injection changes back [/Users/hardy/work/hibernate/core/trunk/core/target/classes/org/hibernate/Version.class] [INFO] [resources:testResources {execution: default-testResources}] [WARNING] Using platform encoding (MacRoman actually) to copy filtered resources, i.e. build is platform dependent! [INFO] Copying 1 resource [INFO] [compiler:testCompile {execution: default-testCompile}] [INFO] Not compiling test sources [INFO] [surefire:test {execution: default-test}] [INFO] Tests are skipped. [INFO] [jar:jar {execution: default-jar}] [INFO] Building jar: /Users/hardy/work/hibernate/core/trunk/core/target/hibernate-core-3.6.0-SNAPSHOT.jar [INFO] [source:jar-no-fork {execution: attach-sources}] [INFO] Building jar: /Users/hardy/work/hibernate/core/trunk/core/target/hibernate-core-3.6.0-SNAPSHOT-sources.jar [INFO] [install:install {execution: default-install}] [INFO] Installing /Users/hardy/work/hibernate/core/trunk/core/target/hibernate-core-3.6.0-SNAPSHOT.jar to /Users/hardy/tmp/m2/org/hibernate/hibernate-core/3.6.0-SNAPSHOT/hibernate-core-3.6.0-SNAPSHOT.jdocbook-style [INFO] Installing /Users/hardy/work/hibernate/core/trunk/core/target/hibernate-core-3.6.0-SNAPSHOT-sources.jar to /Users/hardy/tmp/m2/org/hibernate/hibernate-core/3.6.0-SNAPSHOT/hibernate-core-3.6.0-SNAPSHOT-sources.jar [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1 minute 15 seconds [INFO] Finished at: Fri May 28 15:29:33 CEST 2010 [INFO] Final Memory: 43M/211M [INFO] ------------------------------------------------------------------------ {noformat} The maven version is: _Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)_ Strong was able to reproduce the problem on his Fedora box, but on this Mac it works. -- 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

14 years, 11 months

5
13
0 / 0

[Hibernate-JIRA] Créée: (HHH-2389) Improving DB2 dialect

by Nicolas Billard (JIRA)

Improving DB2 dialect --------------------- Key: HHH-2389 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2389 Project: Hibernate3 Type: Improvement Components: query-hql Versions: 3.2.1 Environment: Development based on v 3.2.1 Reporter: Nicolas Billard Priority: Minor Attachments: DB2Dialect.java The class joined to this issue overrides the DB2 dialect. The dialect included in hibernate doesn't work very well when you want to limit returned results (when you call setFirstResult and / or setMaxResults on a query) : - the instructions "fetch first XXX row only is not used - a temporary table is used when it's not usefull - when you have subselects, an exception can occur if subselects have order by clause (because of the getRowNumber method, not corrected here). This version of getLimitString() method generates faster requests (tests made on a table of 300000 rows shows that fetching rows from 20 to 30 takes 0.3 seconds with original version, 0.02 with this one). -- 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

14 years, 11 months

3
5
0 / 0

[Hibernate-JIRA] Created: (HHH-5007) Using <formula> within Composite Element inside Collection

by Hepoi Ko (JIRA)

Using <formula> within Composite Element inside Collection ---------------------------------------------------------- Key: HHH-5007 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5007 Project: Hibernate Core Issue Type: Patch Components: core Affects Versions: 3.5.0-CR-2 Environment: 3.5.0-CR2, AS400, Component Reporter: Hepoi Ko Priority: Minor Attachments: JoinWalker.java I was one of the user who use Hibernate in a legacy database schema, and always had a issue on using composite-key (and formula) inside collection. I was able to modify the hibernate source (from 3.3.2) to overcome such issue. I am hoping the new version 3.5.0 would even fix this problem. Anyway, I just leave the fix information here, hope it would help. In /org/hibernate/loader/JoinWalker.java Line 641: String[] aliasedLhsColumns = StringHelper.qualify(alias, lhsColumns); Modify with these: String[] fullAliasedLhsColumns = persister.getElementColumnNames(alias); String[] aliasedLhsColumns = ArrayHelper.slice(fullAliasedLhsColumns, begin, length); Without above change I would get NullPointerException on a mapping as .... <set name="auditRecords" table="OEP40A" order-by="ADAT40 DESC, ATIM40 DESC" mutable="false" inverse="true" outer-join="true"> <key> <column name="CONO40"></column> <column name="ORDN40"></column> </key> <composite-element class="com.ricoh.erp.order.domain.OrderAudit"> <property name="userId"> <column name="AUSR40"></column> </property> <property name="workstationId"> <column name="AWRK40"></column> </property> <many-to-one name="customerEntry" not-found="ignore"> <formula>CONO40</formula>  <column name="CUSN40"></column> <column name="DSEQ40"></column> </many-to-one> </composite-element> With Best Regards, -- 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

14 years, 11 months

3
15
0 / 0

[Hibernate-JIRA] Created: (HHH-4941) Log a message when an update to a mutable one-to-many collection of immutable entities is ignored

by Gail Badner (JIRA)

Log a message when an update to a mutable one-to-many collection of immutable entities is ignored ------------------------------------------------------------------------------------------------- Key: HHH-4941 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4941 Project: Hibernate Core Issue Type: Improvement Reporter: Gail Badner Assignee: Gail Badner Fix For: 3.5.x An update to a mutable one-to-many collection is ignored when inverse="true" and the associated entity is immutable and already exists (since it cannot be updated). Should this be a debug, info, or warning message? -- 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

14 years, 11 months

2
12
0 / 0

[Hibernate-JIRA] Created: (HHH-4760) NotAuditedException occurs when auditReader.getRevisions() is called for javassist proxies

by Erik-Berndt Scheper (JIRA)

NotAuditedException occurs when auditReader.getRevisions() is called for javassist proxies ------------------------------------------------------------------------------------------ Key: HHH-4760 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4760 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.5.0-Beta-2 Reporter: Erik-Berndt Scheper NotAuditedException occurs when auditReader.getRevisions() is called for javassist proxies In my code I see the following stacktrace if I try to retrieve the revision of a javassist proxy: org.hibernate.envers.exception.NotAuditedException: nl.ibgroep.bap.model.domain.persoon.Ouder_$$_javassist_1 is not versioned! at org.hibernate.envers.reader.AuditReaderImpl.getRevisions(AuditReaderImpl.java:126) at nl.ibgroep.bap.dao.impl.AuditRevisionJpaDaoImpl.getRevisionsFor(AuditRevisionJpaDaoImpl.java:58) Ouder_$$_javassist_1.class is a Hibernate generated javassist proxy for Ouder.class, which is versioned. Code: AuditReader vr = AuditReaderFactory.get(this.entityManager); Class clazz = persistentObject.getClass(); List<Number> revisionNumbers = vr.getRevisions(clazz, persistentObject.getId()); I am able to work around this issue with the following code: AuditReader vr = AuditReaderFactory.get(this.entityManager); Class clazz = persistentObject.getClass(); if (persistentObject instanceof javassist.util.proxy.ProxyObject) { if (LOGGER.isDebugEnabled()) { StringBuilder output = new StringBuilder("Found javassist ProxyObject for revision: class= "); output.append(clazz.getSimpleName()); output.append("; superclass= ").append(clazz.getSuperclass().getSimpleName()); output.append("; interfaces= ").append(Arrays.asList(clazz.getInterfaces()).toString()); LOGGER.debug(output.toString()); } clazz = clazz.getSuperclass(); } List<Number> revisionNumbers = vr.getRevisions(clazz, persistentObject.getId()); However, a fix in envers would be greatly appreciated. -- 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

14 years, 11 months

4
3
0 / 0

[Hibernate-JIRA] Created: (HHH-5016) Add support for initialValue on sequence generation

by Morten Egelund Rasmussen (JIRA)

Add support for initialValue on sequence generation --------------------------------------------------- Key: HHH-5016 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5016 Project: Hibernate Core Issue Type: Improvement Reporter: Morten Egelund Rasmussen I'm having an entity with a @javax.persistence.SequenceGenerator annotation: {code} @SequenceGenerator(name = "foo.pkseq", sequenceName = "MY_SCHEME.SEQ_FOO_ID", allocationSize=1, initialValue=100) {code} I have set "hibernate.hbm2ddl.auto = create". When the sequence is created, it is created without the initialValue properly set. Referring to the documentation on Hibernate Annotations 3.4, it states that this feature is currently not implemented. I have tried with the H2 and HSQLDB databases. I'm doing some integration tests, where records are created in a RAM-based H2 or HSQLDB test database. The database is already populated with 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

14 years, 11 months

4
3
0 / 0

[Hibernate-JIRA] Created: (HHH-1994) Problem with case sensitive column and tables names and Identity mapping with postgreSQL

by Alex Samad (JIRA)

Problem with case sensitive column and tables names and Identity mapping with postgreSQL ---------------------------------------------------------------------------------------- Key: HHH-1994 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1994 Project: Hibernate3 Type: Bug Components: core Versions: 3.1.3 Environment: Hibernate 3.1.3, Java 1.5.0_07 (sun) windos and linux ( 32 & 64 bit). POstgres SQL 8.1 Windows and linux Reporter: Alex Samad Whilst trying to insert into a table with a primary key (ID mapping) which has a identity generator. And the columns and/or the table has been defined with case sensitivey ie back ticks. It fails to get the next serial number and thus fails any inserts. The problem lies in dialect/PostgreSQLDialect.java public String getIdentitySelectString(String table, String column, int type) { return new StringBuffer().append("select currval('") .append(table) .append('_') .append(column) .append("_seq')") .toString(); } table is inclosed in quotes and column is inclosed in quotes which gives a name like "table"_"Column"_seq - which fails I would suggest a fix is to test each of table or column for " and if it exist then to strip it of both of table and column and encluse the whole name in "". This mighe break some old code where say the table is coded in case insensitive table name and case sensitive column key. Sorry not much of a java programmer. -- 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

14 years, 11 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-5025) Support caching audit queries using ehcache's DiskStore.

by Brent Worden (JIRA)

Support caching audit queries using ehcache's DiskStore. -------------------------------------------------------- Key: HHH-5025 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5025 Project: Hibernate Core Issue Type: Improvement Components: envers Reporter: Brent Worden Priority: Minor Enabling audit query caching with a ehcache cache configured as persisting to disk or overflowing to disk. For example, <defaultCache diskPersistent="true" eternal="false" maxElementsInMemory="1000" maxElementsOnDisk="10000" overflowToDisk="true" timeToIdleSeconds="300" timeToLiveSeconds="3600" /> Results in the following exception: java.io.NotSerializableException: org.hibernate.envers.entities.RevisionTypeType at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) The lack of needed serialization prohibits the use of ehcache's DiskStore. -- 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

14 years, 11 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2655) SQLServer2005Dialect (ROW_NUMBER for Paging)

by Wells Tiedeman (JIRA)

SQLServer2005Dialect (ROW_NUMBER for Paging) -------------------------------------------- Key: HHH-2655 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2655 Project: Hibernate3 Issue Type: New Feature Components: core Affects Versions: 3.2.4, 3.2.3, 3.2.2 Environment: SQLServer 2005, Hibernate 3.2.2+ Reporter: Wells Tiedeman Attachments: SQLServer2005Dialect.java Add a SQLServer2005Dialect class to the product that leverages the new ROW_NUMBER capabilities within SQLServer2005 to do paged result sets more efficiently. See attached source... -- 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

14 years, 11 months

14
25
0 / 0

[Hibernate-JIRA] Created: (HHH-2893) Criteria api does not allow a groupProperty to _NOT_ be included in the selected columns

by Antony Stubbs (JIRA)

Criteria api does not allow a groupProperty to _NOT_ be included in the selected columns ---------------------------------------------------------------------------------------- Key: HHH-2893 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2893 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.5 Environment: n/a Reporter: Antony Stubbs When adding a Projections.groupProperty("prop") to a criteria, the property is added to both the GROUP BY and SELECT parts of the generated SQL query. This is a major problem for using the criteria API for complex subselects that require aggregating by a column while grouping by another column. There is presently no way in the criteria API to group by a column and have it _ONLY_ in the GROUP BY clause. i.e. currently Projections.groupProperty("propOne") causes: SELECT propOne, MAX(propTwo) FROM table GROUP BY prop desired option is to have SELECT MAX(propTwo) FROM table GROUP BY prop There have been several people talking about this, but there appears to have been 'no comment'. http://forum.hibernate.org/viewtopic.php?t=939071&highlight=values+groupp... http://forum.hibernate.org/viewtopic.php?t=950803&highlight=groupproperty... http://forum.hibernate.org/viewtopic.php?t=964512&highlight=groupproperty... http://forum.hibernate.org/viewtopic.php?t=957671&highlight=groupproperty... http://forum.hibernate.org/viewtopic.php?p=2317841#2317841 http://forum.hibernate.org/viewtopic.php?t=961617&highlight=groupproperty... Find a 1st cut patch on it's way - I'm just itching my scratch now... Great work on Hibernate guys! -- 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

14 years, 11 months

4
11
0 / 0

[Hibernate-JIRA] Created: (HHH-3325) Pagination with Oracle ROWNUM is sub-optimal

by e. wernli (JIRA)

Pagination with Oracle ROWNUM is sub-optimal -------------------------------------------- Key: HHH-3325 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3325 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.5 Reporter: e. wernli Pagination with Oracle ROWNUM is sub-optimal The feature works but result in sub-optimal SQL. The generated SQL is the following: select * from ( select row_.*, rownum rownum_ from ( select this_.id as id3_0_, this_.version as version3_0_, this_.name as name3_0_, this_.type as type3_0_, this_.marketstatus as marketst5_3_0_ from Customer this_ order by this_.id asc ) row_ ) where rownum_ <= ? and rownum_ > ? But this SQL is faster: SELECT * FROM (SELECT row_.*, ROWNUM rownum_ FROM (SELECT this_.ID AS id3_0_, this_.VERSION AS version3_0_, this_.NAME AS name3_0_, this_.TYPE AS type3_0_, this_.marketstatus AS marketst5_3_0_ FROM customer this_ ORDER BY this_.ID ASC) row_ WHERE ROWNUM <= ?) WHERE rownum_ > ? The second solution allows Oracle to use an optimization that can dramatically reduce the time of the query, especially one of the first page is retrieved. See this link for an explanation of this optimization: http://decipherinfosys.wordpress.com/2007/08/09/paging-and-countstopkey-o... -- 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

14 years, 11 months

7
8
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 May 2010