Audittrail Changein Mx5

1
I use the Audittrail module from the appstore in all of my apps - it is great! While I don't need to view the audit information often, when I do, it provides fantastic detailed information about every change that has happened on an object and all of its attributes, references, etc. When I installed the new version that has been upgraded for Mx5, I noticed that the AudutiTrailSuperClass entity no longer stores createdDate, changedDate, owner, and changedBy. Since I use these entities in my applications, I wanted to see if someone from Mendix (or from the community) can offer insight into why these system attributes are no longer stored by this module. I am wondering if there would be harm in changing this entity to track these attributes. Thanks, Mike
asked
3 answers
0

I don't know why they were removed but I can imagine there is a serious performance impact if they are left there, especially for applications with tens of millions of rows in the audittrail object. From what I understand they're also not really needed for the functionality of the module.

answered
0

Those fields where intentionally removed because of the overhead (as Bas indicates).

Most of the time those fields are not necessary, if you really need it you can always add those fields back.
For your information, those fields have been removed in the version where a new option for auditing has been added. Having those system fields and not using them can slow down your app for no good reason.
Another thing in the Audit trail module that slows your application down is having all entities inherit from the same superclass entity. That is a slow process that isn't really necessary.

See the documentation on how to improve this:
Below is the part of the documentation on how to improve your performance on entities that you want to audit. This is especially relevant if the entities are changed quit often.

Association & events (you should use this option)

  • Add a reference association from the 'AuditTrail.Log' entity to the entity that needs to be audited.
  • Add an After Create, Before Commit and Before Delete event to your entity identical to the events on the AudittrailSuperClass.
  • The Java actions will automatically create the log item and all required loglines based on the changes
  • Configure the constant: 'LogOnlyChangedAttributes' whether or not you want to log all attributes or just the changes
  • Add the 'AuditTrailOverview' form to your navigation.

Inheritance: (avoid this option)

  • All objects that you would like to log need to have the AuditTrail.AudittrailSuperClass as a superclass except the subclasses of the System.User object.
  • The module automatically logs all changes on the create, commit and delete event.
  • Configure the constant: 'LogOnlyChangedAttributes' whether or not you want to log all attributes or just the changes
  • Add the 'AuditTrailOverview' form to your navigation.
answered
0

Bas - New answer because my response was too long.

Thanks for the response. I can imagine performance impact too - however, the entity I was asking about was the one that is used as the generalization for objects where you want to track changes. The actual log and logline entities where change information is stored track all of the system attributes, so I guess the performance impacts have been anticipated during development.

Mike

answered