Hi Sergio,
I updated my code with your changes, and it still doesn't seem to be
working. I don't have the history Manager in my model.
Is it working for you? Are you using the latest trunk?
Thanks!
Erik
On Aug 19, 12:15 pm, Sérgio Durand <[EMAIL PROTECTED]> wrote:
> Hi people,
>
> Finally i'
Hi Erick,
It was working on r8339.
I've updated django this morning to r8460 to and still working !!
What is "history Manager" that you said ?
look how i'm using audit trail:
1) i have my 'ordinary' model (without audit trail feature)
2) i get the audit trail code and drop it into site-packages
Sérgio,
Sorry about the **kwargs thing, my fault. I'm the one who patched
AuditTrail to reflect the newest version of Django, but since I have
some custom code in there I had to go line-by-line and figure out what
to bring back to the website. I missed the **kwargs thing, though, it
seems.
-Larr
I would (and do) implement audit trails right in the database itself
using the trigger and procedure language that your database provides.
In this manner, any front-end application writing to the database will
have the audit-trail by default, without need for front-end
application support.
In ot
Thank you for the advice, David -- you make a good point.
How would you track which Django user made which change? Perhaps I
could subclass models.Model so save() always fills an (uneditable)
field 'updated_by' with the current user. Likewise, we could have an
(editable) field "reason_for_chang
Hi Jason,
On Fri, 2007-04-20 at 13:30 -0400, Jason McVetta wrote:
> I need to add real audit trail and change-notification support to an
> existing Django app and to one that is under development. The best
> way to do this, it seems to me, is to add audit support to the Django
> framework itself
> I will be working on this project as part of my Real Job(tm),
> so devoting time to it should not be a problem. However,
> before I begin coding, I want the community's input on a few
> issues.
>
> What is the right way, at DB level, to implement the audit
> trail? I had two ideas:
Todd Schr
2007/4/20, Jason McVetta <[EMAIL PROTECTED]>:
> I need to add real audit trail and change-notification support to an
> existing Django app and to one that is under development. The best way to
> do this, it seems to me, is to add audit support to the Django framework
> itself. My requirements ar
On 4/20/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> In your descriptions below, you remove the ability for a developer to
> use manual primary keys, by the sound of it, since one of your special
> fields wants to be a single-column primary key. That's not invisible.
Does Django currentl
On 4/21/07, Tim Chase <[EMAIL PROTECTED]> wrote:
>
> Todd Schraml authored a good article in Dr. Dobb's Journal
> (http://www.ddj.com/dept/database/184406340) titled _Table
> Patterns & Changing Data_ where he discusses five patterns for
> keeping historical data, and the requirements that would le
On 4/23/07, David Larlet <[EMAIL PROTECTED]> wrote:
>
> It's a bit ugly to declare instance hidden variables (pre) but we need to
> be
> sure that the save/delete is effective (post) before logging it.
>
It's not beautiful, perhaps, but I may end up doing something very similar.
However, one requi
What about doing both? Write a pre_save record indicating the
operation about to be attempted. And a post_save indicating the
success of the operation, using a unique identifier to identify the
pair. Then if the post_save gets out of sync, you have a record of
transactions that may be at fault.
On 4/24/07, robin_percy <[EMAIL PROTECTED]> wrote:
>
> What about doing both? Write a pre_save record indicating the
> operation about to be attempted. And a post_save indicating the
> success of the operation, using a unique identifier to identify the
> pair. Then if the post_save gets out of s
Here is my current thinking:
- No changes to main model tables
- Designate a model to be audited by including inner class "Audit"
- One shadow table per audited model
- Generate shadow tables for all audited models on post_syncdb
- Only write to one DB, until multi-db support is com
You could have a look at Marty Alchin's Pro Django (not really for
beginners but ...) on page 263 where he shows how to do almost exactly
what you describe. If you got that book it would accelerate your
progress in Django anyway. The only downside is it was published in 2008
and Django has move
Enrico,
I've done this in the past. I didn't use Django directly for the
audit
tables. Instead I defined DB triggers on each primary table that
inserted a row of audit values into the audit table. I can send you
sample trigger code that works in Oracle and My
Hi Mike,
thanks for that reference, I will take a look.
Enrico
--
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
Hi Fed,
the DB trigger approach sounds very exciting to me because I really need to
be sure that there is no way to manipulate records without audit trail. I
also would be very interested in the trigger code for MySQL you mentioned.
You also mentioned that you did something similar in the past
Thinking about this topic more detailed made me realize that I also need to
track the user who performed the insert/change (delete is globally not
permitted) actions. However, that are user names managed via Django ... so
when i use DB triggers I only can track the MySQL user who is used by the
Enrico,
the DB trigger approach sounds very exciting
to me because I really need to be sure that there is no way to
manipulate records without audit trail. I also would be very
interested in the trigger code for MySQL you mentioned.
OK. I'll append s
Enrico,
In the sample MySQL trigger code of my previous message, you'll
see that I always store, in the primary table, the string username
of the most recent user to update the table. Therefore, that value
is available to the DB trigger as NEW.update_user.
On Saturday 21 January 2017 04:15:34 enrico baranski wrote:
> I'm quite new to Django and currently experimenting with
the database
> model. Defining fields appears to be quite intuitive and is
well
> described in the documentation. However, I am looking
into audit
> trail functionalities.
Don'
Django Field History is a great project to audit trail a model field
On Saturday, January 21, 2017 at 7:19:57 AM UTC-5, enrico baranski wrote:
>
> Hi all Django users,
>
> I'm quite new to Django and currently experimenting with the database
> model. Defining fields appears to be quite intuitive
@Fred: Thanks a lot, that really helped me!
enrico
--
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 g
No progress so far. I know I can do this:
attrs[field.name] = copy.copy(field)
if attrs[field.name].rel:
attrs[field.name].rel.related_name = "audit_%s_%s" %
(cls.__name__,
field.name)
But this doesn't seem to make a difference. I still get:
Error: One or
25 matches
Mail list logo
