Originally when I wanted to get into web development, I was looking for a good Python framework to learn. I’ve been following Django for a while, and have been impressed by the community that has sprung up around it. After some major life changes, new found familiarity with CSS and HTML5, and the Django 1.4 release, I decided it was finally time to jump in. These are some of the speed bumps I encountered while starting my first few projects beyond Django’s tutorial Poll app.
I decided to try using choice sets for a few fields. They are nice in that they let you configure a list of coded values. However, getting at the long form descriptions was a puzzle to me initially. Before I noticed the
get_FOO_display() function, a friend pointed me to this Stack Overflow question. The last entry was perfect for my needs:
def get_display(key, list): d = dict(list) if key in d: return d[key] return None
I suspect that with a little effort, I should only need to rely on
get_FOO_display(). However, with a free standing choice list,
get_display() may come in handy.
Dumping your data
During the early stages of fleshing out a model, one generates a nice set of data. While one could manually recreate it, it quickly reaches the tipping point of tediousness. In the course of developing your data model, there comes a time when you will want to modify your data structure in a way that will conflict with a previous version. For me, this first came trying to add a BooleanField and getting the following error message: “no such column”. I updated my model and ran
syncdb, what do you mean no such column?!? With some assistance, best I could figure is that Django didn’t know what to do with the previous rows. Since I’m still in the very early stages of designing my app, I decided to dump and rebuild my database.
While it is not outside of the realm of possibility to manually re-enter the 4 rows (plus related entries) I had already accumulated, that can be a major pain to do so. I know there are tools like South to help with data migrations, but that is overkill for my needs at this point. Fortunately, Django provides a way to save off and reload your data. This is what I worked out for my toy projects (having an sqlite database in
python manage.py dumpdata [appName] --indent 2 > dumpfile.json rm database.db python manage.py syncdb python manage.py loaddata dumpfile.json
Delete the database, re-sync everything, load the file. Magic.
python manage.py runserver
Took me a few missteps to remember this command to enable the development web service accept outside HTTP requests. Figured that was as good a sign as any to write this one down. Excerpt from the Django tutorial:
If you want to change the server’s IP, pass it along with the port. So to listen on all public IPs (useful if you want to show off your work on other computers), use:python manage.py runserver 0.0.0.0:8000
Other learning mistakes…
- When setting up a view-template, I naively tried to pass
MyModel.objectswhich does not return a queryset. You need to call a method like
- By having a URL in my main project with pattern “^myapp/$” – that trailing “$” prevented django from looking into my app’s
Other good resources
I stumbled upon this site a while ago: Django by Example which has several good examples including a To-Do list, a simple blog, a photo organizer, a forum, and a calendar. I haven’t tried these yet on 1.4, but am planning to in the near future.
Another good jumping point I’d like to dive into further once I get more comfortable with Django: https://github.com/hjwp/Test-Driven-Django-Tutorial