Needless to say that it would be a pain to manually convert it from the better 0.7 format back into 0.6, so I wrote a fairly small python script, that does the job.

Don’t blame me if the script causes your data to be erased or tables to be dropped. It’s ment as a guideline, although it worked for me out of the box.

YMMV.

Usage: python <south_07to06.py> <path/to/migration.py>

import sys
import re
 
create_table_re = re.compile("db.create_table('([^']+)',")
field_name_re = re.compile("^(s*)('([^']+)', self.gf")
 
cur_model = None
 
input = open(sys.argv[1])
 
for line in input.readlines():
    line = line.rstrip()
    match = create_table_re.search(line)
 
    if line.startswith("class Migration"):
        line = "class Migration():"
    elif line.startswith("from south.v2"):
        continue
    elif 'Meta' in line and 'object_name' in line:
        line = re.sub(r"(?:, )?'object_name': '[^']+'", "", line)
 
    if not cur_model and match:
        cur_model = match.group(1)
    elif cur_model and line.strip() == '))':
        cur_model = None
    elif cur_model:
        field_match = field_name_re.search(line)
 
        if field_match:
            spaces = field_match.group(1)
            field_name = field_match.group(2)
            line = "%s('%s', orm['%s:%s']), " % (spaces, field_name, cur_model.replace("_", "."), field_name)
 
    print line

Until recently I’ve been using the file:// django cache, but that has a “problem” when multiple users needs to manipulate the cache (think uid 80 writes a key, that uid 1000 wants to delete).

My problem with the memcached:// django cache provider has been, that it cannot handle being used on a shared memcached instance, because of the danger of key collissions.

If project A and project B would share a memcached instance, they basiclly share the same global namespace. So if they both write a key called actor there is no telling what will happen.

So I wrote a little cache backend for django, that uses the current memcached backend, but adds a pre-defined prefix to all keys.

Usage: Put the code somewhere inside your project in a file called memcachedkeyprefix.py, and set your CACHE_BACKEND to something like: path.to.memcached_key_prefix:///127.0.0.1:11211/?keyprefix=sewc&foo=bar&timeout=3600

"Memcached cache backend with key prefixing"
 
from django.core.cache.backends.base import InvalidCacheBackendError
from django.core.cache.backends.memcached import CacheClass as MemcachedCacheClass
from django.utils.encoding import smart_unicode, smart_str
 
class CacheClass(MemcachedCacheClass):
    def __init__(self, server, params):
        try:
            self._key_prefix = smart_str(params['key_prefix'])
        except KeyError:
            raise InvalidCacheBackendError('key_prefix not specified')
 
        super(CacheClass, self).__init__(server, params)
 
    def _get_key(self, key):
        return self._key_prefix + smart_str(key)
 
    def add(self, key, value, timeout=0):
        return super(CacheClass, self).add(self._get_key(key), value, timeout)
 
    def get(self, key, default=None):
        return super(CacheClass, self).get(self._get_key(key), default)
 
    def set(self, key, value, timeout=0):
        return super(CacheClass, self).set(self._get_key(key), value, timeout)
 
    def delete(self, key):
        return super(CacheClass, self).delete(self._get_key(key))
 
    def get_many(self, keys):
        keys = [self._get_key(key) for key in keys]
        return super(CacheClass, self).get_many(keys)
 
    def incr(self, key, delta=1):
        return super(CacheClass, self).incr(self._get_key(key), delta)
 
    def decr(self, key, delta=1):
        return super(CacheClass, self).decr(self._get_key(key), delta)

Seeing as how there are a lot of benefits to using djangos own test suite (fixtures and automatic database generation to name a few), i set out to write a little test client for PyAMF to utilize django’s test client, so it would be possible to write a proper test suite.

This turned out great, and is now ticket 508 over at PyAMFs trac. Look at the client.py for the code. At some point, it will be integrated into PyAMF mainline as p.r.c.django.TestClient (or something like that).

We used to have a url schema consisting of the following components:

    [dev.|test.]<project-name>.<client-name>.companyname.tld

That made for very long url’s, and furthermore, the url’s would not be supported by a *.companyname.tld. Based on this infomation, and wanting to create a more generelized, nicer url schema, we choose to cross over to the following schema:

   [dev-|test-]<project-name>.companyname.tld

Which besides from supporting a wildcard ssl certificate just fine, just, well, looks nicer.

Either way, me beeing in charge of the contents in /etc/, and getting a little sick of growing apache configuration files, I chooose to write some macros to configure our project sites.

We generally have 2 types of project sites. django based sites, and PHP based sites.

A typical django apache configuration consists of a VirtualHost and some mod_python settings inside a Location block. Lot’s of configuration, very little actual diffrence between the configration projects in between.

An example of a django based application running inside a apache VirtualHost, could look like this:

    <VirtualHost *:80>
        ServerName test-project.company.tld
        <Location />
            SetHandler python-program
            PythonHandler django.core.handlers.modpython
            PythonPath "['/path/to/project', '/other/path/to/inject']"
            SetEnv DJANGO_SETTINGS_MODULE project.settings
        </Location>
        <Location /media/>
            SetHandler none
        </Location>
        Alias /media/admin/ /path/to/django/contrib/admin/media/
        Alias /media/ /path/to/project/media/
    </VirtualHost>

And the on top of that comes SSL configuration, auth and such. 25 lines of configuration per django site. Now, I really wanted to acomplish two things.

• Make the configuration easier to maintain
• Enable other users to setup sites without knowing the depths of django and mod_python

Now, apache configuration, meet mod_macro. The solution to my problem was very simple. Create a macro that handles all the django configuration, given 4 parameters. A server name (i.e. the url), the parent directory of the django site and the module name of the site.

So i started building my macro.

    <Macro DjangoSite $servername $root $module>
        <VirtualHost *:80>
            ServerName $servername
            <Location />
                SetHandler python-program
                PythonHandler django.core.handlers.modpython
                PythonPath "['/common/path/to/inject', '$root']"
                SetEnv DJANGO_SETTINGS_MODULE $modulename.settings
            </Location>
            <Location /media/>
                SetHandler none
            </Location>
            Alias /media/admin/ /path/to/django/contrib/admin/media/
            Alias /media/ $root/$module/media/
        </VirtualHost>
    </Macro>

mod_macro is really simple, it will do a longest-match search and replace on the macro’s content. So, if we had a django site in /path/to/djangosite/testsite/ the above macro could be used as:

    Use DjangoSite www.example.org /path/to/djangosite/ testsite

Which would expand to:

    <VirtualHost *:80>
        ServerName www.example.org
        <Location />
            SetHandler python-program
            PythonHandler django.core.handlers.modpython
            PythonPath "['/common/path/to/inject', '/path/to/djangosite/']"
            SetEnv DJANGO_SETTINGS_MODULE testsite.settings
        </Location>
        <Location /media/>
            SetHandler none
        </Location>
        Alias /media/admin/ /path/to/django/contrib/admin/media/
        Alias /media/ /path/to/djangosite/testsite/media/
    </VirtualHost>

Hope you find this infomation a little useful. I actually like looking at our apache configuration file now.