[Hibernate-JIRA] Created: (HSEARCH-678) @NumericField does not work with BigDecimal types (and others?)
by Nick Fenwick (JIRA)
@NumericField does not work with BigDecimal types (and others?)
---------------------------------------------------------------
Key: HSEARCH-678
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-678
Project: Hibernate Search
Issue Type: Bug
Affects Versions: 3.3.0.Final
Environment: Hibernate 3.6.0, MySQL 5.1.52, Fedora Core 14
Reporter: Nick Fenwick
This is my first JIRA so please help me assigns its Component above correctly.
My first attempt to use BigDecimal ran into trouble trying to use the new @NumericField annotation. The SessionFactory fails to create an instance of the session. The code:
{{
@Column(name="val")
@Field(name="val", index=Index.UN_TOKENIZED, store=Store.YES)
@NumericField
private BigDecimal val;
}}
Results in the exception:
{{
Exception in thread "main" java.lang.ExceptionInInitializerError
[cut]
Caused by: org.hibernate.HibernateException: could not init listeners
[cut]
Caused by: org.hibernate.search.SearchException: Unable to guess FieldBridge for val
at org.hibernate.search.bridge.BridgeFactory.guessType(BridgeFactory.java:250)
at org.hibernate.search.engine.AbstractDocumentBuilder.bindFieldAnnotation(AbstractDocumentBuilder.java:690)
at org.hibernate.search.engine.AbstractDocumentBuilder.checkForField(AbstractDocumentBuilder.java:564)
[cut]
}}
Taking out the @NumericField allows the session to start up successfully.
I will attempt to make a test case but I'm having local build env issues. 'mvn clean install' of a fresh hibernate search git checkout is taking an incredibly long time (an hour for the first 10 or so .pom files?) so I may be several hours or days over this trivial task.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of 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
[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
14 years, 4 months
[Hibernate-JIRA] Created: (HHH-5992) A query fails to return correct results silently
by Tom Ross (JIRA)
A query fails to return correct results silently
------------------------------------------------
Key: HHH-5992
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5992
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.2
Environment: JBoss EAP 5.1
Reporter: Tom Ross
The following query fails silently to return a correct result select v1.username, v2.username from user_ety v1, user_ety v2 where v1.username = '1' and v2.username = '2'. It returns one row with "1,1" instead of one row with "1,2".
The query works with pre JPA CMP EJBs (ver 2.1) but fails when moved to JPA based persistence.
This failure is very dangerous since it is silent and without manually checking data it is impossible to determine if a correct set is returned.
The workaround is to use aliases and modify the query so it looks like that:
select v1.username as username1, v2.username as username2 from user_ety v1, user_ety v2 where v1.username = '1' and v2.username = '2'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of 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
[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
14 years, 4 months
[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, 4 months
[Hibernate-JIRA] Created: (HHH-6236) NullPointerException in org.hibernate.type.EntityType.isEqual
by Thomas Stinner (JIRA)
NullPointerException in org.hibernate.type.EntityType.isEqual
-------------------------------------------------------------
Key: HHH-6236
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6236
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.4
Environment: Hibernate 3.6.4, MySQL 5.5.8, Linux x64
Reporter: Thomas Stinner
The following error does not occur every time, but in 75% of all program starts.
The error either occurs on one of the first queries to the database, or does not occur at all.
We solve this issue by simply restarting the application and trying again. It also happens with other applications, not only this one.
INFO | jvm 1 | 2011/05/19 10:43:19 | Caused by: java.lang.NullPointerException
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.type.EntityType.isEqual(EntityType.java:344)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.type.ComponentType.isEqual(ComponentType.java:176)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.engine.CollectionKey.equals(CollectionKey.java:71)
INFO | jvm 1 | 2011/05/19 10:43:19 | at java.util.HashMap.put(HashMap.java:376)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.engine.StatefulPersistenceContext.addCollection(StatefulPersistenceContext.java:820)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.engine.StatefulPersistenceContext.addUninitializedCollection(StatefulPersistenceContext.java:789)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.type.CollectionType.getCollection(CollectionType.java:643)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.type.CollectionType.resolveKey(CollectionType.java:431)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.type.CollectionType.resolve(CollectionType.java:425)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:139)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:982)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.loader.Loader.doQuery(Loader.java:857)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:274)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.loader.Loader.loadEntity(Loader.java:2037)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:86)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:76)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3293)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:496)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:477)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:227)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:285)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:152)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:1090)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:1038)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:630)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.type.EntityType.resolve(EntityType.java:438)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:139)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:982)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.loader.Loader.doQuery(Loader.java:857)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:274)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.loader.Loader.doList(Loader.java:2533)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2276)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.loader.Loader.list(Loader.java:2271)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:452)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:363)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:196)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1268)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.impl.QueryImpl.list(QueryImpl.java:102)
INFO | jvm 1 | 2011/05/19 10:43:19 | at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:246)
INFO | jvm 1 | 2011/05/19 10:43:19 | at de.schuechen.tms.abrechnung.RechnungenErzeugen.ausRgVorschlag(RechnungenErzeugen.java:106)
INFO | jvm 1 | 2011/05/19 10:43:19 | at de.schuechen.tms.abrechnung.RechnungenReporter.createJasperPrint(RechnungenReporter.java:136)
INFO | jvm 1 | 2011/05/19 10:43:19 | ... 5 more
STATUS | wrapper | 2011/05/19 10:43:22 | TERM trapped. Shutting down.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of 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