Django

Installation

There are a few ways to install Django, perhaps the cleanest and easiest is by using pip. With Python 3+ you will need to install pip3 first, like

# Ubuntu
apt-get install python3-pip

After that, Django is obtained by

pip3 install django==1.10

...and other versions available instead of 1.10 can be specified if needed. An important and popular Django add-on package "tables2" can be added likewise:

pip3 install django-tables2

If one needs to verify the successful installation of this package, the following needs to be done in an interactive Python session before "import" is attempted:

>>> from django.conf import settings
>>> settings.configure() 

To check which version of Django you are using at the moment, start interactive Python and use this:

import django
django.VERSION

Or, something like:

python3 -m django --version

Databases

sqlite

Django comes packaged with a sqlite database. It will work fine for initial development and testing, but it won't handle concurrency in most cases (e.g. multiple clients of same type updating same DB tables). There are a few reasons for that, such as:

• lack of table/row lock capability
• presence of the file lock on the whole DB file

If the application requires any level of concurrency a different DB engine will be needed such as PostgreSQL, MySQL, Oracle etc.

Deploying DB for Django

sqlite permissions

Assuming you are using sqlite, the file permissions on the DB file do matter if when you deploy under Apache. So you either need to set wide permissions (may not be a good idea depending on the security situation) or change the owner to "www-data" (on Ubuntu) or "apache" (on CentOS). Other OS may require similar tweaks.

PostgreSQL

An example of the "settings.py" clause:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'foo',
        'USER': 'bar',
        'PASSWORD': '***',
        'HOST': '',
        'PORT': '',
    }
}

Transactions

Utilizing transactions may become necessary in scenarios when concurrency needs to be handled. In addition, locking specific rows for update can be achieved transparently (if the DB backend supports it) in the following manner:

entries = Entry.objects.select_for_update().filter(author=request.user)

This should be done within a transaction block which perhaps throws an exception if the row is locked.

Database Routers and Migration to a New Database

In case multiple databases are required in the app, one needs to implement database routers. This is not difficult since numerous examples can be easily found. However, there are recipes that must be followed to make migrations work correctly. In the following example, we want to use a newly created database "users" to keep auth/admin info separate from the main content. The migrations should refer to that specific database, and not just to the app name as recommended in a few places:

$ ./manage.py migrate --database=users
# and also requires explicit reference to the database when managing users:
$ ./manage.py createsuperuser --database=users

In the latter command, if the database is not explicitly mentioned, the superuser will be created in the previously deployed database, not in the new instance. Even the prior migration won't change this behavior, so again the exact reference must be there.

The Development Server

Not suitable for real life deployment, as the name suggests it's for development only. In addition to potential security issues, it may be challenging for thread safety unless one disables multithreading. If you want to access the development server on a local network, from a different computer, the command line below can serve as an example of how to start it:

./manage.py runserver 0.0.0.0:8000

If 0.0.0.0 is skipped, the server will work but won't be accessible from a different machine.

Admin Pages

Serving Styles for Amdin pages on a real Web server

There is plenty of information on setting up the correct function of the Django Admin pages, however there is one thorny item which is styling these pages when running on a real Web server (they will style correctly on the development server but this may break).

The simplest recipe I found so far (and I think I invented this myself) is to just copy the needed sources from the "admin" folder in your Django package tree, into the "static" directory, assuming you have configured the latter correctly for your Web server. For example,

sudo cp -r /usr/local/lib/python3.5/site-packages/django/contrib/admin/static/admin /var/www/static

fixes the problem.

Admin password reset

Start Django shell:

python manage.py shell

...and check superusers:

from django.contrib.auth.models import User
User.objects.filter(is_superuser=True)

For a given user, the password can be set as follows:

usr = User.objects.get(username='your username')
usr.set_password('raw password')
usr.save()