October 2010 - hibernate-issues - Jboss List Archives

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

by Sanne Grinovero (JIRA)

Improve support for all language specific snowball Analyzers in Lucene/contrib ------------------------------------------------------------------------------ Key: HSEARCH-461 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-461 Project: Hibernate Search Issue Type: Improvement Reporter: Sanne Grinovero Fix For: 3.3.0 For Lucene 3.1 Robert Muir did a great job of standardazing and cleaning Analyzers in contrib with many languages support (wrapping snowball analyzers); I'd like to look into having some helper in Hibernate Search in setting them up all to be available as analyzers and couple to entities in some clever way. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HHH-5409) bag and idbag should implement equals() and hashCode() the same way as other collections

by Dmitry Katsubo (JIRA)

bag and idbag should implement equals() and hashCode() the same way as other collections ---------------------------------------------------------------------------------------- Key: HHH-5409 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5409 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Reporter: Dmitry Katsubo bags/idbags behave in inconsistent way in comparison to set/list/map in respect to {{equals()}} and {{hashCode()}}. In {{[PersistentBag.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentBag.java?r=HEAD#l510]}} {{equals()}} and {{hashCode()}} methods are commented and in {{[PersistentIdentifierBag.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentIdentifierBag.java?r=HEAD]}} not present. {{[PersistentMap.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentMap.java?r=HEAD#l449]}}, {{[PersistentSet.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentSet.java?r=HEAD#l428]}}, {{[PersistentList.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentList.java?r=HEAD#l484]}} however implement {{equals()}} and {{hashCode()}} methods correctly. The intention of this is clear: to avoid loading of the lazy collection on simple {{equals()}} call. * I think that it is a task for the end application to handle lazy collections as it is aware about this situation. * If there is a strong demand of not loading collections on {{equals()}} call for some applications, I suggest to make this behaviour configurable via additional attribute in XML mapping for all collections. * The behaviour should be documented as suggested in HHH-1642. I personally spend hours debugging before I understood why lists behave differently from bags. Probably relative issues: * HHH-3771 ({{equals()}} for lazy loaded objects) * HHH-1642 ({{equals()}} for {{[AbstractPersistentCollection.SetProxy|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/AbstractPersistentCollection.java?r=HEAD#l636]}}) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

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

12 years, 10 months

4
8
0 / 0

[Hibernate-JIRA] Created: (HHH-5454) With hibernate.order_inserts=true Hibernate executes SQL inserts in wrong order

by Oleg Tsernetsov (JIRA)

With hibernate.order_inserts=true Hibernate executes SQL inserts in wrong order ------------------------------------------------------------------------------- Key: HHH-5454 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5454 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.0.Beta2, 3.3.2, 3.3.1, 3.3.0.SP1 Environment: Initially occurred with hibernate-core 3.3.1, Oracle 11g. Reproduced with hibernate-core 3.3.0 SP1 (and later) and HSQLDB 2.0.0 Reporter: Oleg Tsernetsov Attachments: jpatest.zip *General:* With _hibernate.order_inserts_ configuration property set to _true_ Hibernate executes SQL inserts in wrong order, so that dependent entities are attempted to be inserted before parent entities. This is a production case, so we had to switch off hibernate insert ordering to workaround the problem. *Test case:* Test case for reproduce is attached (jpatest.zip). It uses hibernate-entitymanager 3.4.0.GA (hibernate-core 3.3.0 SP1), hsqldb 2.0.0. The problem is also reproducible in later versions of hibernate-core (3.3.1, 3.3.2, 3.6.0.Beta2). Test case is a typical maven2 project. In order to run the test case: - unzip the archive to any folder - cd jpatest - mvn test If change hibernate.order_inserts to _false_ in /jpatest/src/main/resources/META-INF/persistence.xml, then the test passes. Mappings are located under \jpatest\src\main\resources\META-INF\mappings.hbm.xml *Data model:* [Person] 1 -- * [Phone] [Person] 1 -- * [Relation] * -- 1 [Person] *Scenario:* 1) Insert plain person P1. 2) Update person P1, -- add new phone PH1 to person P1 -- add new relation R1 to person P1. Relation R1 refers to a new person P2 having new phone PH2 Update of person P1 generates insert for phone PH1 and cascade inserts for P2, PH2 and R1. Once inserts are ordered, insert clauses for phones PH1 and PH2 come first. As insert for PH2 is executed before the insert of its parent entity P2, the whole operation fails due to parent key not found. With Oracle DB it results in java.sql.BatchUpdateException: ORA-02291: integrity constraint (PHONE_PERSON_FK) violated - parent key not found With HSQLDB - java.sql.BatchUpdateException: integrity constraint violation: foreign key no parent; PHONE_PERSON_FK table: PHONE *Problematic code* org.hibernate.engine.ActionQueue.InsertActionSorter.findBatchNumber(), uses only _property_ types to determine batch number, but in given case cascade goes through composite primary key of Phone, so the code should also deep-traverse action.getPersister().getClassMetadata().getIdentifierType(). *Another problem* When I tried to change phone collection mapping in Person entity from _<map>_ to _<set>_ (with hope to workaround the issue), then I got another error: java.lang.NullPointerException at org.hibernate.type.AbstractType.getHashCode(AbstractType.java:136) at org.hibernate.type.AbstractType.getHashCode(AbstractType.java:144) at org.hibernate.type.EntityType.getHashCode(EntityType.java:312) at org.hibernate.type.ComponentType.getHashCode(ComponentType.java:212) at org.hibernate.engine.EntityKey.generateHashCode(EntityKey.java:126) at org.hibernate.engine.EntityKey.<init>(EntityKey.java:70) at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:184) 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.DefaultPersistEventListener.entityIsPersistent(DefaultPersistEventListener.java:134) at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:107) 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) at com.test.AppTest.testJPA(AppTest.java:77) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Please pay attention to it as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

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

12 years, 10 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

12 years, 10 months

7
13
0 / 0

[Hibernate-JIRA] Created: (HHH-5303) @Cachable has no effect

by Paul Bakker (JIRA)

@Cachable has no effect ----------------------- Key: HHH-5303 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5303 Project: Hibernate Core Issue Type: Bug Components: caching (L2), entity-manager Affects Versions: 3.5.2 Environment: Tested on HSQL (included in testcase) and MySQL database Reporter: Paul Bakker The JPA 2.0 @Cachable annotation has no effect at all. Just putting @Cachable on a class is not enough to enable caching. You must also configure a concurrency strategy with either @Cache or a hibernate.ejb.classcache setting in persistence.xml. If those settings are in place, @Cacheble still has no effect. Entities are cached, but @Cachable(false) doesn't change this behavior. I included a Maven example project that tests this behavior. The project has two profiles to switch between Hibernate and EclipseLink: mvn -P hibernate clean test mvn -P eclipselink clean test -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

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

12 years, 10 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

12 years, 10 months

2
1
0 / 0

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

by Juraci Paixao Krohling (JIRA)

Hibernate Validator doesn't compiles in OpenJDK 6 ------------------------------------------------- Key: HV-318 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-318 Project: Hibernate Validator Issue Type: Bug Components: build Environment: RHEL5, OpenJDK6 Reporter: Juraci Paixao Krohling Assignee: Hardy Ferentschik /qa/hudson_ws/workspace/hibernate-validator-trunk/jdk/openjdk-local/label/RHEL5_any/trunk/hibernate-validator/src/test/java/org/hibernate/validator/util/TestUtil.java:[66,30] incompatible types; inferred type argument(s) java.lang.Object do not conform to bounds of type variable(s) T found : <T>javax.validation.bootstrap.ProviderSpecificBootstrap<T> required: java.lang.Object -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
12
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues October 2010