Thanks, Collin, Carl, & Tom ~ Is this a reasonable summary of what you have said so far?:
1. You've suggested two solutions, which I'll call "middleware" (from Collin) and "save() argument" (from Carl and Tom). 2. A limitation of both is that they aren't what I'll call "universal". That is, they only work when the update is done with the save() method of a Django data model object (or perhaps with other methods that unleash DB actions, such as update(), that could be customized)in a similar way). Other ways of doing a DB update action - ways that don't go thru save()or other such methods - would fail to set last_updated_by. Questions: What are these "other ways"? Do they include "raw SQL" as discussed in https://docs.djangoproject.com/en/dev/topics/db/sql/, using Manager.raw() or cursor.execute()? Are there any other "other ways"? 3. The difference between the "middleware" and "save() argument" solutions is that "middleware" is "magic", i.e totally invisible to the developer, where "save() argument" is not. I'm a relative newbie to Django, so I'm trying to get clear that I'm understanding you. Assuming that my understanding isn't too far off, let me say that I'm looking for a solution that is "universal" and "magic". (And I'm willing to live with the risks of "magic"). I think this requires a solution at a deeper level of middleware ("deeper" meaning closer to the DB and farther from app code), some level that *all *DB update actions go through. Let me float two more not-even-half-baked ideas for your comments: 1. Stick some code into the database connector, as I described in possibility 1 of my original post. I guess the connector would be the "connection" class? 2. Have Django create a new *database user *for each session login, using the user id that Django knows and that I want to record in the last_updated_by column, and establish a new database connection with that user as the user. Then the database would know the user and could record it in the last_updated_by column for every update in that session. At logout, the database user would be dropped. Do you think a Django app could be programmed to handle the creation and dropping of this user, and to establish a db connection for that user? I will also put this proposal to a PostgreSQL forum to see if they think it would work on the database end. ~ Tx, Ken On Tuesday, October 14, 2014 11:46:40 AM UTC-4, Collin Anderson wrote: > > Hi Ken, > > If you _really_ want it to be automatic, I think your best bet is to use a > middleware to store the user or request object in a "thread local" > variable, and then have a pre_save signal set the last_updated_by field > based on that. That method is frowned upon, but should work. (If you're > doing "green" threading, it may break.) The pre_save signal could error, or > something if it is not able to determine the request (like in the > command-line case). > > Thanks, > Collin > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/465118e1-7fd0-4501-8a56-92332e142bd8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
