1. b.93z.org
  2. Notes

Some aspects of view and model definition with Django

I’ve been using Django since 0.96 from time to time (greenfield development, support, consulting). Across projects I participated in, there is one bad tendency: developers define global per-model ordering via ordering meta option. They rely on this option everywhere: in tests (if there are any :), in code, in command-line scripts; then they change this meta option (say, customer changes requirements) and everything breaks, because order is different now. There are even blog posts that encourage developers to add this global option because “we are lazy” and “abstractions leak”.

Currently I support Django project that uses only 3 of Django’s apps (contenttypes, sessions, messages)—the rest is project’s own apps. As you can see, project does not use admin, and, as there are only two (legacy) apps among project’s own ones where ordering meta option is still set and matters (in all other places ordering is set explicitly via order_by method of QuerySet instances), it helped me completely remove definition of Meta class from most of models.py. In some places, though, index_together option is set.

So far, such approach works pretty well. There is no implicit ORDER BY in new code, so it is more readable and much easier to maintain.

Also project’s code does not use Django’s CBVs. It did use them, but, at the end of the day, they were completely project’s own, so removal of not-so-necessary middle level helped with debugging (and it made code way more readable :)

In addition to this, there are no definitions of __unicode__ method of models anywhere. As it turned out, developers often want different and highly specific output in Python shell, therefore “default” model representation definition is just pointless.

© 2008–2017 93z.org