Django, epix phail. #1

I am working on a project that is using Django.

We have decided to use ‘South’ which is a migration framework which tries to do for django what rails has out of the box.

This is the first posting of many in what will be a series of rants against django, python, stupidity and pride.

First off, lets look at south.

Django models explicitly define the field structure of the table that is going to hold the objects. Now, I quite like that. It means that if I want to find out what fields a model has, I can look at the object definition. Rails does not have that. fields are defined in the db, and, only in recent rails versions is a comment added to the beginning of your model files detailing the structure.

Now, along comes south. and because the structure is explicit, it tries to do something neat. It will attempt to auto-generate the migration for you by introspecting the previous database structure and comparing to the current one. When I encountered that I thought it was lovely, neat, useful, clean.

BUT IT DOES NOT ALWAYS WORK.

It recognises when you ADD things but not when you take them away. So, if you remove a field, when you generate the migration, it sees it, updates its own copy of how the structure should look, but does not emit the code to remove the field from the database.

Ok you think, thats ugly, but not too bad right? The structure of your objects is still correct, you just have an unused column in your table? yeah? huh? huh?

NO.

Your models are broken because even though the structure of your objects is declared explicitly in your model code, when Django instantiates the object from the database, it IGNORES the defined structure in the model, and instantiates the object with all the fields from the database table. And then continues to use those fields as if they are meant to be there.

What TOSH.

Next time….. “Django templates, or ‘how to go quietly, or not so quietly insaner’”

Leave a Reply

Your email address will not be published. Required fields are marked *