Blogger Template by Blogcrowds.

DjangoAudit

Procedure:

  • Download audit file and save inside your project application folder.

  • Edit models file

from django.db import models
import audit

class Person(models.Model):
    first_name = models.CharField(max_length=255)
    last_name = models.CharField(max_length=255)
    salary = models.PositiveIntegerField()
    history = audit.AuditTrail()

    def __str__(self):
        return "%s %s" % (self.first_name, self.last_name)

  • If you need to view the audit information in the admin interface, simply add show_in_admin=True as an argument to AuditTrail.

  • Then run python manage.py sncdb in terminal to take effect

Testing:

  • Test1View.py

from myapp.models import Person

person = Person.objects.create(first_name='Jayapal', last_name='D', salary=50000)
person.history.count()


OutPut:

1

  • Test2View.py

from myapp.models import Person

person = Person.objects.create(first_name='Jayapal', last_name='D', salary=50000)
person.salary = 65000
person.save()
for item in person.history.all():
print "%s: %s" % (item, item.salary)
person2 = Person.objects.create(first_name='Sahab', last_name='Husain', salary=50000)
print "count:", person.history.count()
print "count of person2:",person2.history.count()
print "total count in table Person:",Person.history.count()


OutPut:

Jayapal D as of 2007-08-14 20:31:21.852000: 65000
Jayapal D as of 2007-08-14 20:30:58.959000: 50000
count: 2
count of person2: 1
total count of table Person: 3

  • Tracking Information:
    As you can see, the audit trail is listed with the most recent state first. Each entry also inclues a timestamp when the edit took place. Saves and deletes are both tracked, and can be filtered on via Person.history.filter(_audit_change_type='_') . Do not use underscore, use 'I' for inserts, 'U' for updates, and 'D' for deletes. 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).

For More information Audit+Wiki

Introduction

The Django Debug Toolbar is a configurable set of panels that display various debug information about the current request/response and when clicked, display more details about the panel's content.

Currently, the following panels have been written and are working:

  • Django version

  • Request timer

  • A list of settings in settings.py

  • Common HTTP headers

  • GET/POST/cookie/session variable display

  • Templates and context used, and their template paths

  • SQL queries including time to execute and links to EXPLAIN each query

  • Cache stats

  • Logging output via Python's built-in logging module

Download

  • DebugToolbar or see for latest source code

  • Copy folder in your python site-packages path (/usr/lib/python2.5/site-packages/debug_toolbar

Implementation

  • Edit your project settings.py file

DEBUG = True
MIDDLEWARE_CLASSES = ('debug_toolbar.middleware.DebugToolbarMiddleware',)
INSTALLED_APPS = ('debug_toolbar',)
INTERNAL_IPS = ('127.0.0.1',)
DEBUG_TOOLBAR_PANELS = (
    'debug_toolbar.panels.version.VersionDebugPanel',     'debug_toolbar.panels.timer.TimerDebugPanel',     'debug_toolbar.panels.settings_vars.SettingsVarsDebugPanel',     'debug_toolbar.panels.headers.HeaderDebugPanel',     'debug_toolbar.panels.request_vars.RequestVarsDebugPanel',     'debug_toolbar.panels.template.TemplateDebugPanel',         'debug_toolbar.panels.sql.SQLDebugPanel',     'debug_toolbar.panels.cache.CacheDebugPanel',     'debug_toolbar.panels.logger.LoggingPanel',
)

  • Run your project and see django toolbar in template.

Screen Shots

Introduction

mod_wsgi is an Apache module for serving WSGI-based Python web applications from the Apache HTTP server. Django, along with almost every other Python web framework today, comes bundled with a backend for acting like a WSGI application. Discovering and trying out mod_wsgi really suprised me. It can take a massive beating, and outperforms mod_python in every practical aspect.

The setup

You will need a short Python "bootstrap" script to create a WSGI-handler for your Django project. Here is an example (call it wsgi_handler.py and place it in the root directory of your Django project - the one with manage.py and settings.py):

import sys
import os
import django.core.handlers.wsgi
sys.path.append(os.path.dirname(os.path.abspath(__file__)) + '/..')
os.environ['DJANGO_SETTINGS_MODULE'] = 'projectname.settings'
application = django.core.handlers.wsgi.WSGIHandler()

  • Apache virtualhost to use mod_wsgi

Add the below lines before the endof virtualhost close tag in apache config file

WSGIScriptAlias / /home/user/projectname/wsgi_handler.py

WSGIDaemonProcess projectname user=user group=user processes=1 threads=10

WSGIProcessGroup projectname

  • Restart apache to take effect.

  • In the WSGIDaemonProcess line, you can easily manage the amount of system resources (measured in processes and threads) mod_wsgi should use. In my experience a single process with 10 threads will cover most small and medium loaded websites.

Why?

This is some of the reasons why you should ditch mod_python for mod_wsgi when hosting Django projects:

  • Faster

    The load times of the websites now served with mod_wsgi really surprised me. Normally a page would be served within 150-300 ms. This was reduced to load times in the range of 40-80 ms.

    I also discovered that running mod_wsgi in embedded mode (as opposed to daemon mode) was not worth the effort. I didn't really see any difference between load times when using Django.

  • Less memory usage

    Everyone hosting more than a couple of Django projects on a single Apache instance knows that Django projects squanders a bit with memory usage, and every single Apache child process will easily end up using 50 MB RAM.

    mod_wsgi dedicates a process (or multiple processes) to a single interpreter for a single Django project, and keeps the memory usage low in the "normal" Apache child processes. On a server with 8 small Django projects, I went from using ~1500 MB RAM on Apache child processes to using 150 MB.

  • Secure

    When using mod_python your Python interpreter will be running as the user running the Apache webserver itself (on Debian systems, the user is called www-data). Typically this will allow you to peek around in places where you do not want your users peeking. This is due to the fact that www-data must have read access to every file you use in your application (including settings/configuration/media files).

    mod_wsgi addresses this problem by changing to a user id specified in the configuration file, and run your Python interpreter as another user than www-data, allowing you to lock down every project on your server to seperate user accounts.

These points cover mod_wsgi running in daemon mode

Newer Posts Home