3 Replies Latest reply on Apr 29, 2008 8:32 AM by Adam Warski

    Audit Storage Strategy

    Anthony Whitford Newbie

      It would be helpful to see an explanation of the audit storage strategy. (I couldn't see this mentioned in the documentation.) I am curious to know if the versioning is field oriented or revision oriented, and whether it uses one set of tables for all auditing, or a set of tables per entity.

      In addition to resurrecting an entity from a point in time (an idea already mentioned), we need to capability to see the revision log between two dates.

        • 1. Re: Audit Storage Strategy
          Adam Warski Master

          Hello,

          I'm not quite sure what do you mean by "audit" - it's possible that my English is failing here :). If you mean a document explaining what tables are created and what values are inserted there and why, I'll try to put one together and publish it this week.

          What do you mean by "revision log"?

          Adam

          • 2. Re: Audit Storage Strategy
            Anthony Whitford Newbie

            Apologies for the confusion -- I should have used a consistent nomenclature...

            I meant to say that I am interested in seeing documentation on the underlying schema that stores the historical versions. Actually, the ant documentation does suggest some background information as to the schema: http://www.jboss.org/envers/schema.html

            So basically, you are storing a complete copy of the object per revision. Do you have a convenient mechanism to perform a "diff" between two points in time, or two revisions?

            Can you explain why revision_timestamp is a bigint instead of a datetime/timestamp?

            Can you explain why there doesn't seem to be a foreign key constraint between _versions._revision and _revisions_info.revision_id?

            Have you thought about tracking a delete event? (An insert would arguably create the first revision, and an update would create an additional revision. From the revision id, we know when the revision happenned. But, what about a delete? There is no indication when a delete happenned.)

            • 3. Re: Audit Storage Strategy
              Adam Warski Master

              Hello,

              I've put up a page, hopefully explaining some of the things:
              http://www.jboss.org/envers/tables.html.
              If there's anything missing (there surely is :) ), please let me know.

              So basically, you are storing a complete copy of the object per revision. Do you have a convenient mechanism to perform a "diff" between two points in time, or two revisions?

              That's in my "todo" list, as you can see the @Versioned annotation takes a parameter, ModificationStore. Right now it has only one value - full, but it will also contain diff.


              Can you explain why revision_timestamp is a bigint instead of a datetime/timestamp?

              I tried using a date, but then milliseconds where lost. And I want to store the dates with millisecond precision.


              Can you explain why there doesn't seem to be a foreign key constraint between _versions._revision and _revisions_info.revision_id?

              There should be, thanks for spotting that :) I'll add it in the next release.


              Have you thought about tracking a delete event? (An insert would arguably create the first revision, and an update would create an additional revision. From the revision id, we know when the revision happenned. But, what about a delete? There is no indication when a delete happenned.)

              Deletes are tracked, when an entity is deleted, a row in the versions table is created with revision type DEL, and the data that the entity contained.

              --
              Adam