Home/ Questions/Q 529243
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T09:04:17+00:00

I guess it’s a good practice to capture auditable fields to track what happened

  • 0

I guess it’s a good practice to capture auditable fields to track what happened to a particular entity (say createdBy, creationDate, modifiedBy, modifiedDate)

  1. I am assuming if an object is never modified it makes sense just to capture the following auditable fields for an SNMPv3 event (say createdBy, creationDate)

  2. I am assuming if an object is modifiable post creation by multiple people, example a User profile can be modified by self or admin then it would make sense to capture all the above attributes (say createdBy, creationDate, modifiedBy, modifiedDate)

  3. Assuming a history of audit trail per entity is not required, would it make sense to store all auditable attributes in the entity itself

  4. Would it make sense to delegate auditing to a 3rd party framework (say JBoss Envers – http://www.jboss.org/envers) for the above use cases.

  5. Assuming an entity (say a Purchase Order) is created and maintained by User X, and User Y makes some refinements to the above PO. Who should be marked as the owner of this entity (is it the creator or the modifier). creationDate in this case might not be of any relevance at all, so would it make sense to track this field here.

Note: The underlying persistence layer is based on JPA, Hibernate 3.3.x

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    (1) and (2) seem reasonable although it probably wouldn’t hurt to treat all entities the same rather than complicate it with create-only and create/modify entities.

    (3) Storing them on the entity is the simplest, but I would be tempted to have a single table or table per entity just for the audit data. That would give you flexibility in case you wanted to store multiple modifications, i.e. the full history. And possibly a slight performance improvement when querying the main entity.

    (4) Envers looks interesting and easy, but it seems to store a full history and you indicated that wasn’t necessary so it might be overkill.

    (5) I’d say the creator is always the person (or process) that caused the initial insert and modifier is the last person/process that caused an update. If you want to make business decisions about the owner, treat that as separate field rather than as part of your auditing solution.

    • 0