Changes between Version 4 and Version 5 of AuditTrail

Timestamp:

Aug 27, 2007, 9:05:39 AM (17 years ago)

Author:

George Vilches <gav@…>

Comment:

--

AuditTrail

@@ -58 +58 @@
 Saves and deletes are both tracked, and can be filtered on via {{{ Person.history.filter(_audit_change_type='_') }}}.  Do not use underscore, use 'U' for inserts/updates, and 'D' for deletes.  If #4879 lands, then we will be able to distinguish between inserts and updates, and at that point the audit trail will use 'I' for inserts and 'U' for updates.
 
+ForeignKeys and OneToOneFields are now supported both for saving and accessing the audit data.  However, it does not archive the contents of the ForeignKey table for the appropriate entries at the same time, and will fail if the ForeignKey a given audit entry is related to is deleted (including if you're auditing the ForeignKey table as well, it does not have a way to link the two audit tables together).
+
 == Caveats ==
-
-Also, in order to copy the fields from the original model to the audit model, it uses some hackery I'm not particularly proud of. It seems to work for all the cases I would have hoped it would, but it relies on the arguments passed to the Field class being named the same as the attributes stored on the Field object after it's created. If there's ever a time that's not the case, it will fail completely on that Field type.
-
-Speaking of which, it fails completely on `ForeignKey`s and `ManyToManyField`s, something I've yet to remedy. That's definitely a must-have, but I haven't worked out the best way to go about it. And since this whole things isn't something I'm particularly interested in, I'm probably going to leave that up to somebody else to work out.
+This needs testing!  This has only been used in a few cases, there's plenty of possible room for strangeness.  It has specifically not been tested for things like safe (de-)serialization.
+
+In order to copy the fields from the original model to the audit model, it uses some hackery I'm not particularly proud of. It seems to work for all the cases I would have hoped it would, but it relies on the arguments passed to the Field class being named the same as the attributes stored on the Field object after it's created. If there's ever a time that's not the case, it will fail completely on that Field type.
+
+It fails completely on `ManyToManyField`s, something I've yet to remedy. That's definitely a must-have, but I haven't worked out the best way to go about it. And since this whole things isn't something I'm particularly interested in, I'm probably going to leave that up to somebody else to work out.
 
 It currently copies and overrides the model's `__str__` method, so that it can helpfully describe each entry in the audit history. This means, however, that if your `__str__` method relies on any ''other'' methods (such as `get_full_name` or similar), it won't work and will need to be adjusted.