[Hibernate-JIRA] Created: (HHH-6605) Storing information about changes of properties
by Michał Skowronek (JIRA)
Storing information about changes of properties
-----------------------------------------------
Key: HHH-6605
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6605
Project: Hibernate Core
Issue Type: New Feature
Components: envers
Affects Versions: 4.x
Reporter: Michał Skowronek
Users would be able to construct more meaningful audit queries if Envers had an option to store and query information about modifications of individual properties, e.g.:
getAuditReader().createQuery().forRevisionsOfEntity(clazz, false, false)
.add(AuditEntity.id().eq(id)).add(AuditEntity.property(propertyName).hasChanged());
With such a query, user will get only those revisions of (clazz, id), that modified property with propertyName.
Currently, to achieve that, user have to retrieve and compare manually two revisions, which increases complexity and decreases performance.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[Hibernate-JIRA] Created: (HHH-3853) one-to-one mapping doesn support Primary Key Association
by Amar Singh (JIRA)
one-to-one mapping doesn support Primary Key Association
--------------------------------------------------------
Key: HHH-3853
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3853
Project: Hibernate Core
Issue Type: Bug
Components: envers
Environment: Hibernate - core 3.4.0-SNAPSHOT, Hibernate - envers (trunk build from today)
Reporter: Amar Singh
Attachments: one-to-one-pk.zip
one-to-one mapping with primary key association doesn't seem to be working. Eg.
Code:
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping package="org.hibernate.envers.test.integration.onetoone.bidirectional" default-lazy="false">
<class name="BidirectionalRefIngPK" table="BIDIRECTIONAL_REFERENCING_ENTITY">
<id name="id" type="long" column="BIDIRECTIONAL_REFERENCING_ID" >
<generator class="foreign">
<param name="property">reference</param>
</generator>
</id>
<property name="data"/>
<property column="BIDIRECTIONAL_REFERENCING_ID" generated="never" insert="false" lazy="false" name="id" type="long" update="false"/>
<one-to-one name="reference" cascade="save-update" class="BidirectionalRefEdPK" constrained="true" />
</class>
<class name="BidirectionalRefEdPK" table="BIDIRECTIONAL_REFERENCED_ENTITY">
<id name="longId" type="long" column="BIDIRECTIONAL_REFERENCED_ID">
<generator class="native"/>
</id>
<property name="data"/>
<one-to-one name="referencing" cascade="all" class="BidirectionalRefIngPK" />
</class>
</hibernate-mapping>
When we try to load a BidirectionalRefIngPK, the underlying query invokes RelatedAuditExpression and since its not a foreign-key based one-to-one association the loading fails in method addToQuery of RelatedAuditExpression at line 52 (relatedEntity==null) with the following exception:
Code:
"This criterion can only be used on a property that is a relation to another property."
TO REPRODUCE
~~~~~~~~~~~~~
Please find a zip file attached which has four files:
- BidirectionalPrimaryAssociation.java (actual testng test case)
- BidirectionalRefEdPK.java (Entity 1)
- BidirectionalRefIngPK.java (Entity 2)
- mappings.hbm.xml
Please put the three java files in its package (org.hibernate.envers.test.integration.onetoone.bidirectional) and the mapping file in src/test/resources.
Now when you run envers tests you should see the failure.
Thanks for this great component !
--
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, 1 month
[Hibernate-JIRA] Created: (HHH-6689) DefaultMergeEventListener changes CheckNullability flag - not thread save
by John SMith (JIRA)
DefaultMergeEventListener changes CheckNullability flag - not thread save
-------------------------------------------------------------------------
Key: HHH-6689
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6689
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.5
Environment: Websphere Application Server 7.0, DB2, Windows Server, Hibernate 3.6.5
Reporter: John SMith
saveTransientEntity() method saves the CheckNullability setting, changes it using the getFactory().getSettings().setCheckNullability method, and does save processing. After save processing, the saved value is restored.
During load testing, we have had situations where the CheckNullability becomes set to TRUE and causes failures because of null checks.
It has been difficult to debug, but it appears that this is not thread safe - multiple threads accessing this method can change the value of this setting.
It can also be that a database error can cause an exception that will cause the checkNullability flan not to be reset.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[Hibernate-JIRA] Created: (HHH-6957) Throw PropertyValueException if there are unresolved entity insert actions after persist/save/merge listeners execute
by Gail Badner (JIRA)
Throw PropertyValueException if there are unresolved entity insert actions after persist/save/merge listeners execute
---------------------------------------------------------------------------------------------------------------------
Key: HHH-6957
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6957
Project: Hibernate Core
Issue Type: Improvement
Components: core
Reporter: Gail Badner
Assignee: Gail Badner
Fix For: 4.1.0
The current behavior (before this proposed change) is kind of complicated when an entity has a non-nullable, transient reference that is not resolved by cascading.
When CHECK_NULLABILITY is true:
- persist/save/merge event listeners will throw PropertyValueException;
When CHECK_NULLABILITY is false:
- if the entity insert action is executed before the session is flushed (i.e., an "early" insert to generate an identity ID), then JDBCException is thrown;
- otherwise, TransientObjectException is thrown when the owning entity is dirty-checked.
The proposed change would make the behavior consistent for all of these cases. If there are any "unresolved" non-nullable, transient entities after the top-level persist/save/merge event executes, then TransientObjectException would be thrown, regardless of the CHECK_NULLABILITY setting.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month