[Hibernate-JIRA] Created: (JPA-14) OPTIMISTIC_FORCE_INCREMENT is not incrementing version field of non-dirty entities
by Behrang Saeedzadeh (JIRA)
OPTIMISTIC_FORCE_INCREMENT is not incrementing version field of non-dirty entities
----------------------------------------------------------------------------------
Key: JPA-14
URL: http://opensource.atlassian.com/projects/hibernate/browse/JPA-14
Project: Java Persistence API
Issue Type: Bug
Environment: MySQL 5.1.53 with InnoDB, Hibernate 3.1.6 Final, Java 1.6.0_22
Reporter: Behrang Saeedzadeh
According to the JPA 2 spec:
{quote}
If transaction T1 calls {{lock(entity, LockModeType.OPTIMISTIC_FORCE_INCREMENT)}} on a versioned object, the entity manager must avoid the phenomena P1 and P2 (as with {{LockModeType.OPTIMISTIC}}) and must also force an update (increment) to the entity's version column. A forced version update may be performed immediately, or may be deferred until a flush or commit. If an entity is removed before a deferred version update was to have been applied, the forced version update
is omitted.
{quote}
However, Hibernate is not incrementing the version field when the entity is not altered in the transaction:
{code}
final EntityManager em = factory.createEntityManager();
em.getTransaction().begin();
VersionedEntity entity = em.find(VersionedEntity.class, id);
em.lock(entity, LockModeType.PESSIMISTIC_FORCE_INCREMENT);
em.getTransaction().commit();
em.close();
{code}
However, the spec says ??must also force an update (increment) to the entity's version column?? and does not give the option to ignore updating the version number if the entity was not dirty.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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, 7 months
[Hibernate-JIRA] Created: (HHH-6042) To much columns in select queries after creating criteria with join
by Karol Kowalczyk (JIRA)
To much columns in select queries after creating criteria with join
-------------------------------------------------------------------
Key: HHH-6042
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6042
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.6
Environment: <dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate</artifactId>
<version>3.2.6.ga</version>
</dependency>
Any database
Reporter: Karol Kowalczyk
Attachments: AbstractEntityJoinWalker.java, Loader.java
When I create criteria for any class with any value of property of association f.e.:
java code:
eventDCriteria = DetachedCriteria.forClass(Event.class);
personDCriteria = eventDCriteria.createCriteria("participants");
personDCriteria.add(Expression.eq("age", 41));
List<Event> events=(List<Event>)getHibernateTemplate().findByCriteria(eventDCriteria, 0, 2);
class mappings:
<class name="Event" table="EVENTS">
<id name="id" column="EVENT_ID">
<generator class="native"/>
</id>
<property name="date" type="timestamp" column="EVENT_DATE"/>
<property name="title"/>
<set name="participants" table="PERSON_EVENT" inverse="true">
<key column="EVENT_ID"/>
<many-to-many column="PERSON_ID" class="Person"/>
</set>
</class>
<class name="Person" table="PERSON">
<id name="id" column="PERSON_ID">
<generator class="native"/>
</id>
<property name="age"/>
<property name="firstname"/>
<property name="lastname"/>
<set name="events" table="PERSON_EVENT" >
<key column="PERSON_ID"/>
<many-to-many column="EVENT_ID" class="Event"/>
</set>
<set name="emailAddresses" table="PERSON_EMAIL_ADDR" >
<key column="PERSON_ID"/>
<element type="string" column="EMAIL_ADDR"/>
</set>
</class>
a Hibernate still creates select query f.e.:
select e.EVENT_ID, e.EVENT_DATE, e.title, pe.EVENT_ID, pe.PERSON_ID, p.PERSON_ID, p.age, p.firstname, ...
from EVENTS e
inner join PERSON_EVENT pe on pe.EVENT_ID=e.EVENT_ID
inner join PERSON p on p.PERSON_ID=pe.PERSON_ID
where p.age=?;
Why this hibernates query have UNNECESSARY list of columns: pe.EVENT_ID, pe.PERSON_ID, p.PERSON_ID, p.age, p.firstname, ...?
This query is not INDEXONLY for any databases.
More EFFECTIVE query is:
select e.EVENT_ID, e.EVENT_DATE, e.title
from EVENTS e
inner join PERSON_EVENT pe on pe.EVENT_ID=e.EVENT_ID
inner join PERSON p on p.PERSON_ID=pe.PERSON_ID
where p.age=?;
A prepared only for my two changes in hibernate: Loader.java and AbstractEntityJoinWalker.java to get more effective selects.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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, 7 months
[Hibernate-JIRA] Created: (HSEARCH-728) Backport MassIndexer to 3.1.X
by Chris Hornsey (JIRA)
Backport MassIndexer to 3.1.X
-----------------------------
Key: HSEARCH-728
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-728
Project: Hibernate Search
Issue Type: Task
Components: massindexer
Affects Versions: 3.1.1.GA
Environment: Hibernate 3.3.X and any jboss server platform prior to 6.0.
Reporter: Chris Hornsey
Anyone using a non JPA2 version of hibernate is unable to utilize the capabilities of the MassIndexer introduced in version 3.2 of search. At a cursory glance I can not determine a dependency of the new indexer on JPA2.
It would be very beneficial to make this available as utilizing hibernate search on existing application and manually indexing is obviously difficult with this new massindexer.
Also anyone who chooses to use a supported version of jboss is excluded from this functionality until most likely 2012.
If this is not possible i would appreciate an explanation of the dependencies the massindexer has on search 3.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
12 years, 7 months
[Hibernate-JIRA] Created: (HSEARCH-682) DSL cannot handle fieldBridge for @IndexEmbedded fields
by Nick Fenwick (JIRA)
DSL cannot handle fieldBridge for @IndexEmbedded fields
-------------------------------------------------------
Key: HSEARCH-682
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-682
Project: Hibernate Search
Issue Type: New Feature
Components: engine
Affects Versions: 3.3.0.Final
Environment: Hibernate 3.6.0, HSearch 3.3.0, Mysql 5.1.52.
Reporter: Nick Fenwick
Discussed in https://forum.hibernate.org/viewtopic.php?f=9&t=1009440, "Re: Correct to use ignoreFieldBridge for "subentity.field" DSL?".
I find I have to set ignoreFieldBridge when querying for a field indexed using @IndexEmbedded, i.e.:
{code}@Entity
class CategoryEntity {
@Column(name="lft")
@Field(name="left", index=Index.UN_TOKENIZED, store=Store.YES)
@FieldBridge(impl=PadNumberBridge.class,
params = { @Parameter(name="pad", value="4") }
)
private int left;
... same for 'right' ...
}
@Entity
class ItemEntity {
@IndexedEmbedded(depth=1)
private CategoryEntity category;
}{code}
results in fields for ItemEntity being stored in the Lucene index like:
{code}
category.left = 0004
category.right = 0012
{code}
To query for these, I cannot do:
{code}
qb.range().onField("category.left").above(4).createQuery()
{code}
I get an exception saying it doesn't know what FieldBridge to use for "category.left". Instead, I can do:
{code}
qb.range().onField("category.left").ignoreFieldBridge().above(4).createQuery()
{code}
but the 'value' is no longer padded according to the FieldBridge that was specified in CategoryEntity for its 'left' attribute, I have to pass value as e.g. "0004".
It would be good to mention this situation in the documentation (5.1.2. "Building a Lucene query with the Hibernate Search query DSL"), at least to specify that it is/isn't supported, so that people attempting this kind of @IndexEmbedded mapping know how to safely build a query for such fields.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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, 7 months
[Hibernate-JIRA] Created: (HV-425) AbstractMethodError in WebLogic 10.3.4
by Torsti Töllinen (JIRA)
AbstractMethodError in WebLogic 10.3.4
--------------------------------------
Key: HV-425
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-425
Project: Hibernate Validator
Issue Type: Bug
Components: engine
Affects Versions: 4.2.0.Beta1
Environment: WebLogic 10.3.4
Hibernate Validator 4.2.0.Beta1
Spring Framework 3.0.5
Reporter: Torsti Töllinen
Validation fails on WebLogic 10.3.4 with HV 4.2.0.Beta1. WebLogic has been patched with patch QWG8 (Enable JPA 2.0 support on WebLogic Server. CR/BUG 9923849).
With WebLogic version 10.3.3, HV works.
java.lang.AbstractMethodError: org.apache.openjpa.persistence.PersistenceProviderImpl.getProviderUtil()Ljavax/persistence/spi/ProviderUtil;
at javax.persistence.Persistence$PersistenceUtilImpl.isLoaded(Unknown Source)
at org.hibernate.validator.engine.resolver.JPATraversableResolver.isReachable(JPATraversableResolver.java:61)
at org.hibernate.validator.engine.resolver.DefaultTraversableResolver.isReachable(DefaultTraversableResolver.java:131)
at org.hibernate.validator.engine.resolver.SingleThreadCachedTraversableResolver.isReachable(SingleThreadCachedTraversableResolver.java:46)
at org.hibernate.validator.engine.ValidatorImpl.isValidationRequired(ValidatorImpl.java:1126)
at org.hibernate.validator.engine.ValidatorImpl.validateConstraint(ValidatorImpl.java:405)
at org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForRedefinedDefaultGroup(ValidatorImpl.java:341)
at org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForCurrentGroup(ValidatorImpl.java:325)
at org.hibernate.validator.engine.ValidatorImpl.validateInContext(ValidatorImpl.java:281)
at org.hibernate.validator.engine.ValidatorImpl.validate(ValidatorImpl.java:129)
at org.springframework.validation.beanvalidation.SpringValidatorAdapter.validate(SpringValidatorAdapter.java:86)
at org.springframework.validation.DataBinder.validate(DataBinder.java:692)
at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.doBind(HandlerMethodInvoker.java:807)
at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.resolveHandlerArguments(HandlerMethodInvoker.java:359)
at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.invokeHandlerMethod(HandlerMethodInvoker.java:171)
at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.invokeHandlerMethod(AnnotationMethodHandlerAdapter.java:426)
at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.handle(AnnotationMethodHandlerAdapter.java:414)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:790)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:719)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:644)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:560)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:183)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3717)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3681)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2277)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2183)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1454)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:207)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:176)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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, 7 months
[Hibernate-JIRA] Created: (ANN-862) Having to use @ForceDiscriminator kind of breaks JPA compatibility
by Albert Kurucz (JIRA)
Having to use @ForceDiscriminator kind of breaks JPA compatibility
------------------------------------------------------------------
Key: ANN-862
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-862
Project: Hibernate Annotations
Issue Type: Improvement
Affects Versions: 3.4.0.GA, 3.5, JPA 2.0
Environment: JPA
Reporter: Albert Kurucz
According to
http://opensource.atlassian.com/projects/hibernate/browse/ANN-36
@ForceDiscriminator was created as a quick workaround to a problem.
Yes, it solves the problem, but it creates a new problem:
the source code which previously had only JPA annotations, now need to be annotated by a Hibernate annotation,
causing that the the source code is now unable to use just any JPA provider.
Major portability issue!
Everyone who likes Open Source, hates Lock-Ins!
My proposal: change the default to a more sane force=true, so that @ForceDiscriminator will not be needed for general JPA projects.
(And create a @DisableDiscriminator Hibernate annotation, for those who like to brake their code).
If changing default behavior is risky, don't fix this on older versions, but lets change this from 3.5.0-Beta2.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[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
12 years, 7 months