[Hibernate-JIRA] Created: (ANN-862) Having to use @ForceDiscriminator kind of breaks JPA compatibility
by Albert Kurucz (JIRA)
Having to use @ForceDiscriminator kind of breaks JPA compatibility
------------------------------------------------------------------
Key: ANN-862
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-862
Project: Hibernate Annotations
Issue Type: Improvement
Affects Versions: 3.4.0.GA, 3.5, JPA 2.0
Environment: JPA
Reporter: Albert Kurucz
According to
http://opensource.atlassian.com/projects/hibernate/browse/ANN-36
@ForceDiscriminator was created as a quick workaround to a problem.
Yes, it solves the problem, but it creates a new problem:
the source code which previously had only JPA annotations, now need to be annotated by a Hibernate annotation,
causing that the the source code is now unable to use just any JPA provider.
Major portability issue!
Everyone who likes Open Source, hates Lock-Ins!
My proposal: change the default to a more sane force=true, so that @ForceDiscriminator will not be needed for general JPA projects.
(And create a @DisableDiscriminator Hibernate annotation, for those who like to brake their code).
If changing default behavior is risky, don't fix this on older versions, but lets change this from 3.5.0-Beta2.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[Hibernate-JIRA] Created: (HHH-3544) Nullability.checkNullability() throws PropertyValueException (not-null property references a null property) for a property that ForeignKeys.Nullifier.nullifyTransientReferences() just nulled
by Jeppe Cramon (JIRA)
Nullability.checkNullability() throws PropertyValueException (not-null property references a null property) for a property that ForeignKeys.Nullifier.nullifyTransientReferences() just nulled
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-3544
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3544
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Environment: Hibernate 3.3.1, Hibernate Annotations 3.4, Hibernate Commons-Annotation 3.3.1, Hibernate EntityManager 3.4, PostgreSQL 8.2.5, Java 5
Reporter: Jeppe Cramon
Attachments: HibernateNullabilityProblem.zip
Nullability.checkNullability throws PropertyValueException (not-null property references a null property) for a property that ForeignKeys.Nullifier.nullifyTransientReferences just nulled.
I've included an Eclipse Java project which can reproduce the problem (didn't include the jars).
The problem requires a pretty big graph to be reproduce able. The file "Domain Model.jpg" displays the Classes that take part in the problem.
The Domain Model is a simplification of the entities from our application.
In the example, ModelTest.java, there's only one active instance entity of each type (from A to H).
With the given test case, when an instance of a is passed to entityManager.persist(..), then the following exception is thrown:
javax.persistence.PersistenceException: org.hibernate.PropertyValueException: not-null property references a null or transient value: dk.hibernatetest.model.C.b
at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:614)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:226)
at dk.hibernatetest.model.ModelTest.test(ModelTest.java:49)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:66)
at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35)
at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: org.hibernate.PropertyValueException: not-null property references a null or transient value: dk.hibernatetest.model.C.b
at org.hibernate.engine.Nullability.checkNullability(Nullability.java:95)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:313)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:144)
at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49)
at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:636)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:628)
at org.hibernate.engine.EJB3CascadingAction$1.cascade(EJB3CascadingAction.java:28)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:291)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:239)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192)
at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:319)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:265)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:242)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192)
at org.hibernate.engine.Cascade.cascade(Cascade.java:153)
at org.hibernate.event.def.AbstractSaveEventListener.cascadeAfterSave(AbstractSaveEventListener.java:479)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:357)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:144)
at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49)
at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:636)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:628)
at org.hibernate.engine.EJB3CascadingAction$1.cascade(EJB3CascadingAction.java:28)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:291)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:239)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192)
at org.hibernate.engine.Cascade.cascade(Cascade.java:153)
at org.hibernate.event.def.AbstractSaveEventListener.cascadeBeforeSave(AbstractSaveEventListener.java:454)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:288)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:144)
at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49)
at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:636)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:628)
at org.hibernate.engine.EJB3CascadingAction$1.cascade(EJB3CascadingAction.java:28)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:291)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:239)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192)
at org.hibernate.engine.Cascade.cascade(Cascade.java:153)
at org.hibernate.event.def.AbstractSaveEventListener.cascadeBeforeSave(AbstractSaveEventListener.java:454)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:288)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:144)
at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49)
at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:636)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:628)
at org.hibernate.engine.EJB3CascadingAction$1.cascade(EJB3CascadingAction.java:28)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:291)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:239)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192)
at org.hibernate.engine.Cascade.cascade(Cascade.java:153)
at org.hibernate.event.def.AbstractSaveEventListener.cascadeBeforeSave(AbstractSaveEventListener.java:454)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:288)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:144)
at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49)
at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:636)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:628)
at org.hibernate.engine.EJB3CascadingAction$1.cascade(EJB3CascadingAction.java:28)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:291)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:239)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192)
at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:319)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:265)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:242)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192)
at org.hibernate.engine.Cascade.cascade(Cascade.java:153)
at org.hibernate.event.def.AbstractSaveEventListener.cascadeAfterSave(AbstractSaveEventListener.java:479)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:357)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:144)
at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49)
at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:61)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:645)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:619)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:623)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:220)
... 21 more
As noted in TestModel.java, if some of the other entities (namely c, g or h) are passed to persist(), then the problem doesn't occur.
I've tried to debug the problem and the only difference I've seen inside ForeignKeys.Nullifier.nullifyTransientReferences() is that, in the cases where an exception is thrown, then the B instance that C.b points to has the state SAVING, whereas when the exception isn't thrown, then it has state MANAGED.
When the B instance has state SAVING, then ForeignKeys.Nullifier.nullifyTransientReferences() nulls then entry in it's value array.
After that, Nullability.checkNullability(), performs a null check, which fails because ForeignKeys.Nullifier.nullifyTransientReferences() just nulled the property in the values array.
Could it be a solution to reverse the order of the ForeignKeys.Nullifier.nullifyTransientReferences() and Nullability.checkNullability() (See AbstractEventListener.performSaveOrReplicate(...))
or does ForeignKeys.Nullifier.nullifyTransientReferences() instead have to take nullability into considerations?
/Jeppe
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[Hibernate-JIRA] Created: (HHH-6738) Hardcoded alias causing problems
by Sven Uibo (JIRA)
Hardcoded alias causing problems
--------------------------------
Key: HHH-6738
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6738
Project: Hibernate Core
Issue Type: Bug
Components: envers
Affects Versions: 3.6.6
Environment: Hibernate 3.6.6-Final, PostgreSQL 9.0
Reporter: Sven Uibo
org.hibernate.envers.entities.mapper.relation.query.TwoEntityQueryGenerator has hardcoded aliases. The "ee" alias is causing problems, because in Estonia most packages start with "ee.". A "_" suffix would be nice.
The exception thrown:
javax.ejb.EJBTransactionRolledbackException: could not resolve property: compname of: SchoolSyllabus_SchoolSyllabusDrivingTopicLog [select new list(ee, e) from SchoolSyllabus_SchoolSyllabusDrivingTopicLog ee, ee.compname.proj.business.entity.syllabus.SchoolSyllabusDrivingTopicLog e where ee.originalId.drivingTopics_id = e.originalId.id and ee.originalId.SchoolSyllabus_id = :SchoolSyllabus_id and e.originalId.ver_rev.id = (select max(e2.originalId.ver_rev.id) from ee.compname.proj.business.entity.syllabus.SchoolSyllabusDrivingTopicLog e2 where e2.originalId.ver_rev.id <= :revision and e.originalId.id = e2.originalId.id) and ee.originalId.ver_rev.id = (select max(ee2.originalId.ver_rev.id) from SchoolSyllabus_SchoolSyllabusDrivingTopicLog ee2 where ee2.originalId.ver_rev.id <= :revision and ee.originalId.SchoolSyllabus_id = ee2.originalId.SchoolSyllabus_id and ee.originalId.drivingTopics_id = ee2.originalId.drivingTopics_id) and ee.REVTYPE != :delrevisiontype and e.REVTYPE != :delrevisiontype]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[Hibernate-JIRA] Created: (HHH-7006) keyword "top" causes test fail on ms sql server
by Strong Liu (JIRA)
keyword "top" causes test fail on ms sql server
-----------------------------------------------
Key: HHH-7006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-7006
Project: Hibernate ORM
Issue Type: Bug
Components: testsuite
Reporter: Strong Liu
Assignee: Strong Liu
Priority: Minor
Fix For: 4.1.0
org.hibernate.ejb.test.cascade.multilevel.MultiLevelCascadeTest.test
{quote}
Error Message
javax.persistence.PersistenceException: org.hibernate.exception.SQLGrammarException: Incorrect syntax near the keyword 'TOP'.
Stacktrace
javax.persistence.PersistenceException: org.hibernate.exception.SQLGrammarException: Incorrect syntax near the keyword 'TOP'.
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1361)
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289)
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295)
at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:976)
at org.hibernate.ejb.test.cascade.multilevel.MultiLevelCascadeTest.test(MultiLevelCascadeTest.java:47)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.hibernate.testing.junit4.ExtendedFrameworkMethod.invokeExplosively(ExtendedFrameworkMethod.java:63)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[Hibernate-JIRA] Created: (HHH-3910) Add support for custom dirty checking during flush
by Ovidio Mallo (JIRA)
Add support for custom dirty checking during flush
--------------------------------------------------
Key: HHH-3910
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910
Project: Hibernate Core
Issue Type: Improvement
Components: core
Affects Versions: 3.3.1
Reporter: Ovidio Mallo
Currently, Hibernate supports a special dirty checking on instrumented entities
in order to improve the flush performance. IMO, this optimization can often be
rather significant. However, the drawback is that you have to use bytecode
instrumentation in order to take advantage of this performance improvement which
might not be an option in some projects.
Therefore, I wanted to propose to extend the current dirty checking during flush
in such a way that the dirtyness information can also be directly provided by
clients. Thereby, I could think of two possible approaches to do this:
1. Introduce an interface which client entities might implement in case they
have some notion of dirtyness. The interface could look something like:
public interface DirtyAwareEntity {
boolean getMightBeDirty();
void setMightBeDirty(boolean mightBeDirty);
}
Using such an interface, Hibernate could easily check whether an entity might
be dirty during flush and it could also reset the dirty flag after flush just
as is currently done for instrumented classes. So this approach would probably
be rather easy to implement and very convenient for clients since they would
only have to implement that interface on the appropriate entities and set the
dirty flag when the entity is actually modified.
2. Add some hooks on event listeners and/or on the Interceptor for querying whether
an entity is dirty and for resetting the dirty flag. E.g. one could add the
following hook method to the DefaultFlushEntityEventListener class:
protected boolean requiresDirtyCheck(FlushEntityEvent event);
By default, this method would call EntityEntry#requiresDirtyCheck(Object entity)
as is done right now.
Resetting the dirty flag could maybe be done in Interceptor#postFlush() or some
dedicated method could be provided.
BTW, I know that currently there already is the Interceptor#findDirty() method which
already allows for some custom dirty checking but the problem from a performance
point of view is that this method requires the entity's property values as parameter
which are retrieved in DefaultFlushEntityEventListener#getValues() which is the most
expensive method during flush. This drawback of the findDirty() method has often been
noticed in comments on the news groups.
I personally think it would be nice if something could be done to improve the
performance of flushing in Hibernate since from what I read on the news groups and
the like, flushing still seems to often lead to performance problems in practice,
especially in larger projects where it is often not easy to avoid flushes or to
keep the numer of entities in the session cache small. In fact, we are having quite
some trouble with that in our project and having some custom dirty checking like the
one I'm proposing here would greatly help in our project and in other projects as
well, I guess.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months