[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5371?page=c... ] Matthew B. Jones updated HHH-5371: ---------------------------------- Attachment: revend_tstmp.txt Provided a patch which enables the outlined REVEND_TSTMP functionality. Also, fixed a minor bug with the collection change events, where it was ignoring ADD and not performing any of the REVEND* functionality, which can lead to issues when removing something from a ManyToMany relationship and then adding it back. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5371?page=c... ] Erik-Berndt Scheper commented on HHH-5371: ------------------------------------------ The patch provided breaks the envers tests of the current trunk. This happens in org.hibernate.envers.test.integration.manytomany.sametable.BasicSametable.java where the column 'REVEND_TSTMP' is missing in Table 'children_AUD' Fix: Line 69/70 should be changed to: {code:title=BasicSametable.java|borderStyle=solid} session.createSQLQuery("CREATE TABLE children_AUD(REV integer NOT NULL, REVEND integer, REVEND_TSTMP bigint, REVTYPE tinyint, " + "parent_id integer, child1_id integer NULL, child2_id integer NULL)").executeUpdate(); {code} -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5371?page=c... ] Erik-Berndt Scheper updated HHH-5371: ------------------------------------- Attachment: HHH-5371-revend_tstmp-revised-20100908.patch Revised patch which should address the comments above. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5371?page=c... ] Erik-Berndt Scheper commented on HHH-5371: ------------------------------------------ Thanks for reviewing the initial patch! I have attached two new patches which fixes the following issues: 1. Use of the end-revision-timestamp is optional, and by default *NOT* enabled. 2. Configuration of this functionaly is ruled by two new properties: * org.hibernate.envers.audit_strategy_valid_time_store_revend_timestamp Used to enable / disable end-revision-timestamp is optional (defaults to *false*) * org.hibernate.envers.audit_strategy_valid_time_revend_timestamp_field_name Used to determine the column nameend-revision-timestamp column (defaults to *REVEND_TSTMP*) 3. I have created a new test class that verifies the behavior of the new end-revision-timestamp column. 4. I have added documentation of the new properties (in a separate patch) -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5371?page=c... ] Erik-Berndt Scheper reassigned HHH-5371: ---------------------------------------- Assignee: Erik-Berndt Scheper (was: Adam Warski) -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5371?page=c... ] Erik-Berndt Scheper commented on HHH-5371: ------------------------------------------ And this also fixes the bug mentioned by Matthew (see above) with the collection change events, where it was ignoring ADD and not performing any of the REVEND* functionality, which can lead to issues when removing something from a ManyToMany relationship and then adding it back. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5371?page=c... ] Erik-Berndt Scheper resolved HHH-5371. -------------------------------------- Resolution: Rejected Fix Version/s: (was: 3.6.0.CR2) Will be fixed after 3.6.0 release -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5371?page=c... ] Adam Warski commented on HHH-5371: ---------------------------------- Somehow I stopped receiving email notifications for the issue :/ Anyway, my main question about rationale was why is the timestamp held for the end-revision, rather then the start-revision? I can see two benefits of using the start-revision: * it never changes - isn't that a requirement for partitioning? * it is available in both audit strategies Also, if the patch fixes some problems with the ValidityAS, I think it should be moved to another issue and another commit. Adam -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5371?page=c... ] Erik-Berndt Scheper commented on HHH-5371: ------------------------------------------ With regard to the rationale why the timestamp is held for the end revision, I'd like to add the following. As a starting point: I believe that audit tables should be partionioned on 'increasing level of interestingness'. I.e. there should (or could) be a partition with audit data that is not very interesting, another for audit data that might be interesting, and one for audit data that is very interesting. Uninteresting audit data should be stored on slow media, interesting audit data should be stored on fast media. To illustrate how this would work, I've prepared a simple example of a salary registration, e.g. for a government agency. The salary table currently contains the following rows for person x: ||year||salary|| |2006|EUR 3300| |2007|EUR 3500| |2008|EUR 4000| |2009|EUR 4500| The salary for the current fiscal year (2010) is unknown. The agency requires that all changes in registered salaries for a fiscal year are recorded (i.e. the audit trail). The rationale behind this is that decisions made at a certain date are based on the registered salary at that time. And at any time it must be possible reproduce the reason why a certain decision was made at a certain date. The following audit information is available, sorted on in order of occurrence: ||year||revtype ||revtimestamp||salary||revend_timestamp|| |2006|ADD|2007-04-01|3300|null| ||year||revtype ||revtimestamp||salary||revend_timestamp|| |2007|ADD|2008-04-01|35|2008-04-02| |2007|MOD|2008-04-02|3500|null| ||year||revtype ||revtimestamp||salary||revend_timestamp|| |2008|ADD|2009-04-01|3700|2009-07-01| |2008|MOD|2009-07-01|4100|2010-02-01| |2008|MOD|2010-02-01|4000|null| ||year||revtype ||revtimestamp||salary||revend_timestamp|| |2009|ADD|2010-04-01|4500|null| To partition this data, the 'level of interestingness' must be defined. Unfortunately, the revtimestamp cannot help here. For example the only revision for year 2006, which is the oldest of all, is still interesting. E.g. it would be very unfortunate if in 2011 there would be an update of the salary for fiscal year 2006 (which is possible in until at least 10 years after the fiscal year) and the audit information would have been moved to a slow disk (based on the oldness of the audit row), because the revend_timestamp must now be updated. Also, look at the typo-error in the salary of fiscal year 2007. Both have nearly the same revtimestamp, but the only interesting row has revend_timestamp= null. I would say that the only column that defines a sensible 'level of interestingness' is the revend_timestamp. A possible division of audit table partitions would be as follows: * revend_timestamp year = 2008 (might not be interesting) * revend_timestamp year = 2009 (potentially interesting) * revend_timestamp year >= 2010 or null (definitely interesting) This also covers the 'problem' of the revend_timestamp update. Despite updating of the revend_timestamp, the audit row remains in what I tend to call the 'extension bucket'. And sometime in 2011, the 'extension bucket' is split into * a partition for all audit rows with revend_timestamp year = 2010 * a partition to contain all rows with year >= 2011 or null I hope this answers the question why the timestamp is held for the end revision. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5371?page=c... ] Erik-Berndt Scheper commented on HHH-5371: ------------------------------------------ Committed rev 20775 which supports this. However, it would probably be good to add an extra chapter to explain partioning, based on the discussion above. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5371?page=c... ] Erik-Berndt Scheper resolved HHH-5371. -------------------------------------- Resolution: Fixed Fix Version/s: 3.6.1 This was already fixed in 3.6.0 Issue marked as resolved now that documentation has been added (GIT rev 2667bb4d728112a45cb37a246f8a4eaff07c644e) -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5371?page=c... ] Erik-Berndt Scheper resolved HHH-5371. -------------------------------------- Resolution: Fixed Fix Version/s: 4.0.0.Alpha1 -- 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