I’ve been hacking away at a side project for the past three or four weeks – got myself to internal milestone #2 this weekend, for which I’m really pleased. The very tail end of this milestone was deploying the code somewhere and vetting that all the basic, mostly-crappy-still bits actually worked.
Since I’ve got it deployed now onto a little dev server, I was thinking about how I was going to make this work going forward. Database migrations being one of those “how do you upgrade things?” questions when you’re doing rapid development django applications where the database model can get twiddled a bit.
The result of scanning around this afternoon from my favorite coffee shop haunt led me to South. In about 10 minutes I’d enabled and moved to south and had my application up and rolling with it. My previous experience was with Django Evolution – which wasn’t bad, but it was more work to get it into place and running.
The migrations in place, I did some model twiddling and experimented a bit to see how it all worked. I can see how if you’re not being somewhat careful, you could get into some really horrible places that no program could figure out. But basic migrations – moving forward and backward – really do an excellent job of “just working” with this framework out of the box.
The one interesting quirk I ran into – I’ve been doing tests on my codebase with:
coverage manage.py test
which just caught and ran the tests for everything in the application list. Figured it didn’t hurt to test the admin and auth stuff as well. When I added south, which I installed using:
pip install south
The directory that south’s tests expect to use suddenly becomes a bit less accessible on the build server. Not a bad thing to redirect the tests to just what I’m writing, but an interesting side effect.
Rhonabwy 