Running manage.py through SSH

I have been having the problem trying to run manage.py on a live server.

Firstly as it is on linux, it is necessary to prepend windows style statements with python.

python manage.py runserver

instead of

manage.py runserver

Also, make sure you are using the correct version of python. E.g:

python2.7 manage.py runserver

If you don’t you will get an error about trying to import django.core.management :

File “manage.py”, line 2, in <module>
from django.core.management import execute_manager
ImportError: No module named django.core.management

Adding admin fields to entities

For many entities it is useful to have created_by, modified_by,  created_date, modified_date fields on the entity.

This is handled by the BasicEntityMixin and the AutoOwnerAdminMixin. 

However do all entities need these fields?

For example simple entities like Country, which at the moment only have the name and id fields (although they may have more fields later), it seems as if this is slightly excessive.

Disadvantages

  1. Database overhead – 4 extra fields for entities that would otherwise just have 2.
  2. Business logic overhead – has to set the extra fields each time.

Advantages

  1. Allows users review who has used the entity in the past – particularly useful for managers on entities that represent someone’s work.
  2. Can check to see who has been tinkering with stuff – although how much of this should be wrapped up in a archiving system.
  3. Allows row based permissions – users can only edit their own items.

Summary

To start with the overhead is so small that it seems irrelevant. It is easier to remove the extra fields later rather than start without them and then add them in – who would you set as the creator, editor, created date etc.

If the overhead becomes an issue then these are 2 key factors:

  1. It is an entity that will be modified regularly (after it’s first creation).
  2. Is it an entity that represents someone’s responsibility or their action – a task, an email, a phone call, a case.
  3. It needs row based permissions (based on who created or altered the entity).

Django Server set up – useful links

I have used Webfaction to get my django site online. They seem very reasonably priced, have servers in Asia (as well as US and UK) and everyone seems to recommend them.

They set the django app up for you, which was quite reassuring on my first release. They create an initial Django project, but you can easily change the app to point at yor own project file by following their instructions.

Everything seemed to go very small issues (and the issue with static files below).

1. On Webfaction the default version of Python appears to be 2.4, so easy_install was installing modules as python 2.4 causing an issue when installing south, the accepted answer on this question sorts things out).

2. When adding my project as the main website, it caused Django to give a 500 error message. On inspecting the log files, I noticed that the module for my app could not be imported. Fixed by editing the python path variable in the httpd.conf file located in the  <your app name>/apache2/conf directory.

Static Files

Having skim read the Django documentation when getting static content working on my dev server, I was shocked to find that none of my static content worked in the live environement.

If you read the static file documentation carefully it says:

  • The development server serves static content to reduce hassle.
  • In a production environment, Django is not optimised for serving static files. Something like Nginx can do it much better. So Django is set up not to serve these files.
  • They provide the tools to make this easy (collectstatic).

You therefore need to set up your own server for static content. This is a great tutorial for setting up Nginx on Webfaction – worked first time (although I didn’t need to do step 4 – as the update indicates it is already installed).

Once that is done, and you have checked it is working, put a couple of test files in the html directory of the Nginx installation and they are served as expected.

To put all your static files in there, edit your django settings file and change the STATIC_ROOT setting to the absolute path of your Nginx Html files. Then run the collectstatic command with manage.py and all your applications static files will be transferred.

Django – row based permissions

Django permissions are powerful, with entity based permissions, that can be applied to users or groups, and are sufficiently granular to control whether a user can view, edit, create or delete items.

 

However, in some case it is important to limit users access based on the actual data in the entity. For example, only being able to edit items that you have created. Or seeing clients that relate to your regional office. Here is a great tutorial that allows those customisations to permissions.

Django – Updating the database structure

The built in dbsync only creates new tables for new models, it does not update tables for existing models with new, altered or removed columns.

Obviously you could edit the db manually – boring, and error prone.

There are some semi automated ways of doing this using the generate sql commands, and tweaking them slightly.

Or it is possible to use a tool to do this. There appear to be a number about, such as south.

Django start up error: No Module named django.core.management

I have been trying to get my first install of django working on a windows machine. While using the django getting started tutorial I had the following error when trying to start the Django server (python manage.py runserver):

C:\PythonDev\MySite>python manage.py runserver
Traceback (most recent call last):
File “manage.py”, line 2, in <module>
from django.core.management import execute_manager
ImportError: No module named django.core.management

This seems to be quite a common error.

I tried some of the fixes suggested, but nothing worked. While tearing my hair out I decided that the python at the beginning of the statement looked a little out of place, and sure enough trying the command without it worked perfectly.

Python Style Guide Summary

Readability is one of the key aspects of Python. The Pep8 style guide suggests how to format your Python code to ensure that your code is easy to read yourself, and by other Python programmers.

Please don’t try and use the list of points below as a  replacement, it doesn’t have many of the points suggested in the full article, but I have found it is a useful quick reference for the standards I had a habit of forgetting:

  1. Indentations should be 4 spaces.
  2. Limit line lengths to 79 characters
  3. Imports should be at the top of the file immediately below any module comments or doc strings.
  4. Imports should be on separate lines.
  5. Imports should be ordered as follows: standard library, third party imports, local imports. Each group should be separated by a blank line.
  6. Use spaces around arithmetic operators.
  7. Do not put unnecessary spaces in and around brackets.
  8. Avoid putting two statements on the same line.
  9. Class names should be in CamelCase.
  10. Function names, function arguments and variables should be lowercase_separated_by_underscores
  11. Private variables and methods should be preceded with _a_leading_underscore
  12. Double underscore attributes are built in system methods, use them but never define your own methods using __double_underscore__

Once you have memorised all those, then there are some useful advice for formatting your doc strings. To be summarised in a future post.