4 Replies Latest reply on Oct 15, 2009 6:37 AM by adamw

    Include a field/property in the Audit/History, but not have

      I have a field (i.e. lastCheckedTimestamp) that checks widgets to see if they've change. If they have changed, I want to have an audited change entry in my audit/history tables and I want to include the 'lastCheckedTimestamp' in that entry. However, if nothing has changed, the timestamp will be updated but I do not want this to trigger an audited change entry in my audit/history tables.

      Basically, I want the field/property to be ignored when it comes to triggering a change entry; but be included in any change entry triggered by something else.

      Is this currently possible?

      Thanks,
      Jamie

        • 1. Re: Include a field/property in the Audit/History, but not h

          Adam? Anyone?

          Thanks,
          Jamie

          • 2. Re: Include a field/property in the Audit/History, but not h
            adamw

            Hello,

            don't be so impatient ;)

            I don't quite understand what you mean by "ignored when it comes to triggering a change entry", but how to control when to audit an entity is described in the FAQ.

            Adam

            • 3. Re: Include a field/property in the Audit/History, but not h

              Adam,

              Sorry for the impatience; my kids must be rubbing off on me. :-o

              Let me try to explain what I'm trying to do a bit better...

              - I have an class, NetworkWidget
              - NetworkWidget has a property named 'lastCheckedTimestamp'
              - NetworkWidget has a method named checkForChanges()
              - NetworkWidget.checkForChanges() will interrogate a given NetworkWidget and compare its current state to its previous state, which is stored in the NETWORK_WIDGET table (i.e. each NetworkWidget has a single row in the NETWORK_WIDGET table representing its last known state)
              - NetworkWidget.checkForChanges() will always update 'lastCheckedTimestamp' regardless of if NetworkWidget changed or not
              - Envers has been added to audit NetworkWidget changes, thus I also have a NETWORK_WIDGET_AUDIT table

              Now, assume the NetworkWidget being interrogated has not had a "real" change. In this case, 'lastCheckedTimestamp' still gets updated, which causes Envers to jump into action and add a new row in the NETWORK_WIDGET_AUDIT table. Though technically correct, I only want to audit "real" changes to NetworkWidgets.

              I know I could tell Envers to not audit 'lastCheckedTimestamp', but that's not what I need either. When a "real" change does happen, I still want 'lastCheckedTimestamp' to be included in the NETWORK_WIDGET_AUDIT table.

              So, I'm looking for a way to include a property/column in the AUDIT table if some other "real" change caused Envers to add a row to the AUDIT table, BUT I don't want just a change to this particular property to cause Envers to add a row to the AUDIT table.

              I was thinking something like this:

               ...
               @NotAuditedButIncluded
               private long lastCheckedTimestamp;
               ...
              


              Does that make any more sense?


              As for the FAQ, I assume you mean this: https://www.jboss.org/community/wiki/EnversFAQ and are referring to the "How to enable/disable auditing at runtime?" entry. That might be doable, but it seems like this is something that could be a bit more straight-forward (e.g. an annotation similar to the one above).

              Am I the only one in need of this functionality? I thought surely there would be others needing this same thing???


              Thanks,
              Jamie

              • 4. Re: Include a field/property in the Audit/History, but not h
                adamw

                Ah I see. And yes, that's the FAQ section I referenced. If you need a fast solution, than I think it's best to extend the Envers listener.

                However if you'd have time to do the "proper" solution - with an annotation as you describe - I'm sure people will find it useful. If you'll be doing any code modifications and need any pointers, let me know :).

                Adam