Audit Storage Strategy

[awhitford]

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.

[adamw]

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

[awhitford]

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.)

[adamw]

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