> In your save method, if self has a value for 'id' we know it already > exists in the database. We can therefore use that id to get another > instance with that ID, fresh from the database. This will have the > *old* values. We can therefore iterate through the attributes of both > the new and old instances - maybe using x.__dict__.items() - and > compare them.
Comparing the instance whose save() method I'm in with another, still intact pre-update instance was something I actually considered doing, but I thought it was a bit "brute-forcey", not the hypothetical elegant solution, which would only involve the changed instance itself, I guess. I was hoping that an instance would have some way of accessing the in- database values of its fields, bypassing the changed fields in their pre-updated state, but I wasn't aware of the fundamental disconnect that you described here: > The key thing to understand here is that a Django model instance is > just a *representation* of an item from the database, it isn't > actually linked to it at all except when you load and save. So, thank you for the clarification. But, having read your response, I thought of another way to (maybe) do it, one that doesn't involve retrieving another instance for an iterative field-by-field check. What I'm considering is a way to override the instance attribute change operation (sm_bar.name = "Just some random model") so that before the change actually takes place, a custom hook saves the old value of the name field into a custom dictionary inside the instance. When the model instance gets saved later on, the save() method checks what keys (representing the names of changed fields) are present in that custom dictionary and constructs the change log entry based on that. No iterating comparisons through the fields of two separate instances would be required. Problem is, I don't know how to do that ;-). The overriding process sounds a lot like something that could be done with Python descriptors (__set__, specifically), but I have zero experience with them. Would this be a feasible approach? Thanks again, JK Laiho --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
