Open andyjefferson opened 8 years ago
Source code and Status can be accessed at DnAuditor Sourceforge Based on discussions are at HOWTO implement Auditable ? Following are the use-cases proposed for this extension.
For example Person Table id name surname version 1 andy jefferson 1 2 Jasper Siepkes 1
After first change ie, converting name into upper case id name surname version 1 ANDY jefferson 2 2 Jasper Siepkes 1 AuditLog Table id objectId fieldName oldValue newValue action version time ObjectType 1 1 name andy andy insert 1 t1 Person 2 1 surname jefferson jefferson insert 1 t1 Person 3 2 name Jasper Jasper insert 1 t2 Person 4 2 surname Siepkes Siepkes insert 1 t2 Person 5 1 name andy ANDY update 2 t3 Person
Only the dirty fields are stored AuditLog table may be split into two table header and dtl. Can be defined by the developer using jdo mapping.
AuditLog table may be split into two table header and dtl. Can be defined by the developer using jdo mapping.
One-One RelationShip - Audit trail TODO : Describe how to capture changes to child objects and relations
TODO : Give examples. Describe how to capture changes to child objects and relations
TODO : Give examples , Describe how to capture changes to child objects and relations
TODO : Give examples. Describe how to capture changes to child objects and relations. Describe how undo buffers are stored.
TODO : Give examples.
TODO : Give examples.
TODO : Give examples.
This was taken from a Wiki post, so put here as a placeholder in case someone can implement it.
I like to implement auditing feature for JDO objects. Auditing means different for different people. So i'll explain my requirements
Req 1 : History :- When an object is created/modified the old and new values are stored in a separate location. This feature is in lines with hibernate-envers. For now this is of low priority.
Req 2 : AuditMaker :- When an object is created/modified the author,role,timestamp should be additionally captured and stored.
Lets study Req2 : AuditMaker can be designed to be part of the domain model ie, create an interface with author,role,timestamp and implement this interface across the domain. This pollutes my domain model, further audit is a cross concern not needed in all projects/customers. I should be enabled only when I need.
Another option is to handle this via metadata. Introduce an annotation @Auditable. All @Auditable classes will automatically get three additional fields. In similar lines with JDO Versioning. With @Version the data object automatically gets a version field.
Another issue is capturing the userid and his role. Need to design some kind of extension point.
Question Where do I start? One option seems to be Lifecycle Callbacks. Since I need to enhance the data object Lifecycle Callbacks may not be a good option. If I choose to write a datanucleus plugin , which plugin point is appropriate for this requirement? Has any one already implemented similar stuff ? Any thoughts on this are welcome.