Thoughts on revision Meta-data

[genman]

I don't think the general meta data problem should be solved as part of the event listeners or revision table. Metadata could be captured by simply by creating an entity, such as "UserChange" which is always inserted along with the transaction (basically every revision) and captures the details of who changed the data and information -- such as if the change was "trivial" or not like one person had asked.

In Envers, you would be able to mark (the primary key?) with some sort of annotation such as @Revision. And maybe @RevisionDate as well. When this entity was inserted, it would be inserted with the proper revision data.

So to get the change log for revision X, the user could do:

UserChange c = EntityManager.find(UserChange.class, X);
c.getUserName();

Actually, to generalize this maybe have the revision entity itself be an @Entity with fields marked with @Revision and @RevisionDate etc. and though the release could have a default implementation, whatever this revision entity was could be customized.

[genman]

To clarify: The user of Envers should have to capture the meta data as part of the transaction and do the insert. So Envers isn't directly involved with this meta data insert except in setting the revision details on this meta data field.

One alternative thought I had was that the meta-data entity "UserChange" (as an example) would be updated in every revision and the find would instead go through VersionsReader instead. Then you wouldn't need to introduce @Revision and @RevisionDate.

Anyway, with whatever approach is made, it should be well documented and used in examples.

[adamw]

Hello,

a very good idea :)

If I understand correctly, it the user would want to persist additional information with each revision (such as: what user modified the data), he would have to create an entity, to which the revision number (obligatorily) and revision date (optionally) would be injected, when the revision is created; the fields would be discovered by marking them as @RevisionNumber and @RevisionDate.

Additionally, he would be able to specify (by a configuration property) a class, which would fill out the rest of the fields. For example - get a Seam Identity component, and set the appropriate user name.

To get the revision data, he would then be able to use:
VersionsReader.getRevisionData(CustomData.class, revisionNumber);

Is that what you meant? :)

--
Adam

[genman]

You have pretty much the idea.

Though I am sort of split on either having the meta-data go into its own table (easier to use with SQL/EntityManager) OR update an existing row and Envars would have to be used to track the latter. The update probably makes less sense.

Somebody on "theserverside" was discussing wanting to store all revisions of data in the same table rather than have a separate table to store the revisions and I suppose if you could store revisions either way, then the meta-data could be stored either way as well. (And then I suppose what you could do with @RevisionNumber is actually populate it when you're storing data in the same table.)

I'm not sure about how effective the callback/configured class might be. In some deployments, like if you use Spring or Microcontainer, it's actually easier to pass an instance variable rather than have the configuration refer to a class that's created at start-up. Consider also using annotations and interfaces as well for configuring the callback.

So working through a few examples (e.g. use Envars in Seam) will make it clear the approach you'd use.

[adamw]

Hello,

see here:
http://www.jboss.org/envers/revision_log.html

I don't quite understand what do you mean by "passing an instance variable"? How would that look like? So far I've implemented it with a callback.

--
Adam