Hi,
1) My need for getting the current user is that I want the following columns on
all tables: created, created_by, updated and updated_by.
So I defined this abstract class which I inherit from on all models:
class AbstractCommonAll(models.Model):
r''' All our tables will be defined with this class. We always want to know
who
created it and when it was done. The same goes for who updated it and when
it was done.
We could either have:
1 A char field for the user.
2 A foreign key to the user table.
If we take option 2 then we must define users for our batch jobs as well
and all the queries
and updates will have to link to the user table. So let us just implement
option 1 for now.
We can always change this at a later stage.
'''
created = models.DateTimeField(editable=False, help_text='When this row
was created')
created_by = models.CharField(max_length=20, editable=False, help_text='Who
created this row')
updated = models.DateTimeField(editable=False, help_text='When this row
was updated')
updated_by = models.CharField(max_length=20, editable=False, help_text='Who
updated this row')
class Meta:
abstract = True
def save(self):
if not self.id:
self.created = datetime.today()
self.created_by = 'user' # we should get this from
request.User.username
self.updated = datetime.today()
self.updated_by = 'user' # we should get this from request.User.username
super(AbstractCommonAll, self).save()
I am still going to implement getting the request.User.username as per ProJango
by Marty Alchin Chapter 11 (page 253 onwards). I could do it in a view but then
I still need it in the saves via admin. I should probably allocate a user for
the batch programs and let them sign on so that they may have authenticated
access and I suspect that I should make this batch user name available to
AbstractCommonAll.save() because there will not be a request structure
available.
2) For Audit/History records see the book ProJango by Marty Alchin Chapter 11
(page 263 onwards) and
http://qr7.com/2010/10/django-simple-history-ftw/ by Corey Bertram.
It handles the Historical records.
There is a possible error (depending upon your naming convention) when the
indexes for the history tables are created:
sql_indexes_for_field() in
/Python26/lib/site-packages/django/db/backends/creation.py creates the database
index with name being model name + column name. This causes a problem for this
implementation of history.
The error is: Failed to install index for myapp.historical_Line model: relation
" myapp_historical_line_type_id" already exists
It happens when the one modelname + foreignkey column name + '_id' is the same
as the referenced modelname + '_id', as in the following example:
class Line_Type(models.Model):
name = models.CharField(max_length=50, unique=True)
description = models.CharField(max_length=100)
class Line(models.Model):
type = models.ForeignKey(Line_Type)
....
So the indexes created would be:
CREATE INDEX " myapp_historical_line*_type_id" ON " myapp_historical_line"
("type_id");
CREATE INDEX " myapp_historical_line_type*_id" ON "
myapp_historical_line_type" ("id");
* is on the model/column name border.
To bypass this error I renamed my linked field (I thought that it would be more
difficult to have sql_indexes_for_field changed [put a specified literal e.g.
'_x_' between model & column names]) as follows:
class Line(models.Model):
line_type = models.ForeignKey(Line_Type)
(PS: I prefixed 'zz' to the history table names so that pgAdmin lists them at
the end of, or after, the 'real' tables).
Regards
Chris
-----Original Message-----
From: django-users@googlegroups.com [mailto:django-users@googlegroups.com] On
Behalf Of Tony
Sent: 30 March 2011 22:27
To: Django users
Subject: Re: model manager and request
yeah, shawn said the exact dilemma I am having. I am working with a
plugged in app and dont want to change its code and mess with its
views and create a new fork, it just seems like small thing to make a
change for (and I would probably mess something else up).
On Mar 30, 11:58 am, Shawn Milochik <sh...@milochik.com> wrote:
> Jacob,
>
> This sort of thing comes up so frequently on this list that we've all
> seen those answers dozens of times, although not usually in so concise
> a manner.
>
> My question, to which there seems to be no answer, is what a good
> approach to do something that I know (from spending a long time on
> this list) is also in high demand: Storing audit information.
>
> Simple requirement:
> Store datetime.now(), request.user, and changes to a model
> automatically on post_save.
>
> Problem:
> The "correct" solutions do not work. If you're using any pluggable
> apps at all you have to fork them or not log them. Refactoring is not
> an option.
>
> I understand why request information is simply not in scope in
> models.py. This isn't a rant or a demand for a fundamental change to
> the way Django works. I'm just looking for either:
>
> 1. A definitive "This is currently impossible in Django."
>
> 2. This is possible with this clever hack/middleware/pseudocode/whatever.
>
> Obviously this method (should it exist) allows a lot of bad designs in
> Django apps. But for the case of applying automatic logging in a
> Django project, it seems like a reasonable desire. Especially given
> that, as Django is a Web framework, there is always a request and
> always a user (even if it's an anonymous user).
>
> Your thoughts would be greatly appreciated. I'll also be attending
> your webinar tomorrow. If you find this question to be in scope or
> have extra time then I'd love to see it addressed.
>
> Thank you,
> Shawn
--
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.
--
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.
