On Mon, Sep 10, 2012 at 11:07 PM, Kurt Pruhs <kpr...@gmail.com> wrote:
> Hey Cal, > > This looks like a great tool. I know I've implemented code like this in > another project. I was planning on doing a field change audit module for an > application I'm currently working on. I will definitely look at > django-cutemodel and see if it works for what I need, and how I can > contribute. > My current project is a time clock system for human resources to manage > hourly workers. We need field change auditing for security, we need the > ability to produce reports from it, and ability to restore from audit > history (in case of record tampering). I think django-cutemodel would be a pretty good fit for this requirement, although it doesn't yet have any sort of administration interface to produce reports, and the documentation isn't exactly great. Restore from audit history functionality is something we need for ourselves too, so I've raised an issue (will prob fix that sometime this week); https://github.com/foxx/django-cutemodel/issues/1 We also need to have the ability to bind the Django User objects together with the event/field change - but some of our clients don't use the Django built-in user/auth stuff - so I need to have a little think about how to satisfy both. https://github.com/foxx/django-cutemodel/issues/2 Basically, all actions are logged and nothing is deleted or over-written. > When changes are made, the original record is marked as a parent archive. > The modified record is a dup of the parent, but with the changes. > The approach of duplicating the row individually could work in some cases, but if there was any unique index constraints then I'm guessing the rows would have to be moved into a different table. If this were the case, you'd need twice the amount of tables, which in itself may be undesirable, plus another which stores the change relationships, plus any changes would have to be done twice. Instead, django-cutemodel doesn't require a sub-table for every model, and the tables don't need to be modified if one of your models changes - it has the following; - table map (stores unique table names) - allows for super fast lookup instead of full text scan - model map (stores unique model + app + db names) - allows for super fast lookup instead of full text scan - fieldchange (stores fieldname+old/new value, target model+pk, and timestamp) - event (stores event message, log level, target model+pk and timestamp) > Anyway, I'm rambling. If you would like to chat about this let me know. I > will update this group, or contact you when I start working on the change > audit code > Sure thing, if you think of any additional changes please feel free to fire them over (it'd be great to see others using this in the wild!) > > Kurt Pruhs > Utah State University > Programing & Design Team > > > > > On Monday, September 10, 2012 1:43:17 PM UTC-6, Cal Leeming [Simplicity > Media Ltd] wrote: >> >> Hi guys, >> >> We have just released a new module that allows for lightweight/easy >> relational event logging and auditing field changes. >> >> Our use case was to satisfy four main requirements; >> >> * Log events directly from models, whilst keeping a relational link to >> the row that triggered the event >> * Keep track of field changes (storing the old/new value). >> * Provide a scalable/easy to use API that allowed access to this >> information >> * Ensure module was a drop-in replacement (only change required is to >> subclass CuteModel) >> >> The code itself has been dragged out of our existing projects, cleaned up >> slightly, and released as open source. >> >> Full documentation and source code has been made available here: >> https://github.com/foxx/**django-cutemodel<https://github.com/foxx/django-cutemodel> >> >> Particular care has been made to ensure the code is able to scale up to >> many millions of rows, and we have not yet had any issues. >> >> In future, we'd love to add some extra features and do a bit more tidy up >> - so any testing/feedback/features suggestions/comments would be >> appreciated. >> >> Cheers >> >> Cal >> > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-users/-/OQzlNQjqtbYJ. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
