December 2008 - hibernate-issues - Jboss List Archives

[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, 3 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, 3 months

4
3
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, 4 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, 4 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, 4 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, 4 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, 4 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, 4 months

2
2
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, 4 months

7
23
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, 4 months

2
16
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, 4 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, 4 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, 4 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, 4 months

2
1
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, 5 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, 5 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, 5 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, 5 months

4
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, 5 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, 5 months

3
21
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, 5 months

32
59
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, 5 months

6
11
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, 5 months

4
17
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, 6 months

2
8
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, 6 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, 6 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, 6 months

2
2
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, 6 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, 6 months

3
4
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, 6 months

2
11
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, 6 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, 6 months

3
5
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, 6 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, 6 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, 6 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, 7 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, 7 months

2
1
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, 7 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, 7 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, 7 months

11
41
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, 7 months

5
5
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, 7 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, 7 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, 7 months

4
6
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, 7 months

6
6
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, 7 months

7
8
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, 8 months

5
4
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, 8 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, 8 months

5
8
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, 8 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, 8 months

4
4
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, 8 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, 8 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, 8 months

4
4
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, 8 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, 8 months

8
13
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, 8 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, 8 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, 8 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, 8 months

4
3
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, 8 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, 8 months

3
4
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, 9 months

5
4
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, 9 months

3
3
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, 9 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, 9 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, 9 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, 9 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, 9 months

3
5
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, 10 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, 10 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, 10 months

2
1
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, 10 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, 10 months

3
4
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, 10 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, 10 months

8
12
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, 10 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, 11 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, 11 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, 11 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, 11 months

5
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, 11 months

3
13
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, 11 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, 11 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, 11 months

2
2
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, 11 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, 11 months

6
11
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, 11 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, 11 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, 11 months

5
7
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

15 years

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

15 years

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

15 years

7
9
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

15 years

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

15 years

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

15 years

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

15 years

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

15 years

4
12
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

15 years

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

15 years

2
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues December 2008