South creates database migrations automatically with only a few commands. Without South, changes require running SQL ALTER statements manually or deleting database tables and recreating them (after creating a backup first, and then restoring it, of course). Taking South into use is really simple: just add "south" to the project settings (under INSTALLEDAPPS_) and run the initial schema migration, which just records current models. After changing models, applying changes to the database requires just two commands:
./manage.py schemamigration <app name> --auto
./manage.py migrate <app name>
This preserves all information in the database, assuming no field was truncated or deleted. So, for example, changing a field from integer to float is fine, but not necessarily the other way around.
South migrations are Python files stored inside the Django app, with names like "0012\auto__del_field_comments__chg_fieldtimestamp.py". That's the 12th migration that was automatically created which deletes the "comments" field and changes the "timestamp" field. South can also handle data migrations: for example, if the timestamp is stored in Unix time (seconds since 1.1.1970) in an integer field, a simple South migration can handle adding a proper DateTime field and converting the timestamps. One caveat with sqlite is that it doesn't support altering unique constraints. However, South gives a warning message when it encounters this - so it's not a hidden surprise to be detected later on.
Sentry is a generic interface for browsing exceptions thrown by Django or by any other Python application. By default, Django emails every single error report to the developer's email address. This is quite annoying with a busy web application: it might send hundreds of emails within a few minutes. Sentry handles this problem by grouping identical error messages as one. In Sentry, "identical" means an error with same traceback, not per client IP address or similar details.
Sentry is installed by adding it to INSTALLED_APPS and adding the middleware to catch exceptions. When running multiple Django applications, a centralized Sentry server is useful. In Futurice, one Sentry server provides access to nearly all Django application error reports (about 15 different applications). The Sentry UI works well, with added Ajax niceties. No system is perfect though: different versions of the Sentry server and client do not always work nicely, and, in case of problems, it fails silently.
Reversion handles version control for objects in the database. Basically, if any object is modified, Reversion saves modifications and allows reverting to old versions. Integration to other parts of applications goes through middleware (adding a single line to the project settings file) or with decorators (for saving changes only in specific methods) or by using "with" statements (for saving changes only in specific places). The easiest way to browse the version history is through the Django admin interface. Reversion even adds automatic comments to versions: for example "Changed description" when the description field was updated.
Hopefully you found a new useful Django tool with the post that will make your development efforts easier in the future!
Futu Connect is our semi-regular roundup of all things Futurice. Be in the know about career-changing events, industry-leading content, non-profit passion projects, and an ever-changing job board.
Enter your email address below.