May 4 2010

Add foreign key constraints in South migration

Béres Botond

Recently I needed to do something specific in a migration. I wanted to add foreign key constraints, but without any other change to models. Basically there was no change to “frozen” models, those were already correct, but somehow the database itself was missing a constraint (legacy database – app has only been converted to South fairly recently). I wanted to avoid raw SQL if possible, but initially looking at the docs I saw a db API method for deleting FK constraint but not for adding one. But after a quick look at the source it turns out there is a simple method:

def forwards(self, orm):
        sql = db.foreign_key_sql('from_table', 'from_field', 'to_table', 'to_field')
def backwards(self, orm):
        db.delete_foreign_key('from_table', 'from_field')

By the way if you develop applications with Django and are not using South yet (or at least some other migration tool), you better check it out, as it is currently the most up to date and stable migration app for it.

Apr 29 2010

Dynamic translation with django-datatrans

Béres Botond

A couple weeks ago I’ve faced the task of adding full i18n support to a large django project, with a lot of legacy code.  Besides dealing with full static i18n coverage, which is not really difficult just tedious and time-consuming, there remained the matter of translating texts stored in the database,  for a lot of models. I expected this to be non-trivial, given my desired requirements:

  • No significant changes required to existing code (ex. querying data, form processing, referring to model fields etc.).  Querying of data based on current language should be transparent.
  • Has a decent interface so that normal users can fill out translations.
  • Ideally it should be fairly recently updated and working well with Django 1.0 – 1.1.
  • Also as few changes to models and/or database structure as possible.  So most likely an app that implements the registration pattern.

What I love about django, besides django itself, is the fact that it has a strong and active community that produces many very useful and stable 3rd party apps.  So the first step was to look around for dynamic translation apps and sure enough there is quite a few of them out there. This great article provides an excellent overview of existing dynamic i18n apps for django. Unfortunately most of them are outdated or do not look too promising. Only one that looked like it could be  a candidate to be deployed on a production environment was django-modeltranslation at first. But then I noticed django-datatrans in the first comment, a fairly new app by Jef Geskens and it soon became the top pick. Although django-modeltranslation is also a good option,  I didn’t like the fact that it adds extra fields for each language on each model, even if it’s done dynamically with registration pattern. Especially that I had a lot of models to work with.

With django-datatrans you have your translations in a single table so your existing database structure is untouched. It’s also stored by hash, so you don’t have multiple records for the same string. The transparent model API works perfectly, I’ve encountered no issues at all so far, after applying it to 50+ models , nor did I have to modify a single line of existing code to make it work. The admin-like interface for editing your translations also will fit most needs, although there is some room for improvement there.  So if you need to translate some of your dynamic data as painlessly as possible, I strongly suggest you check out django-datatrans.