Okay, so maybe my last post was a little heated. Hey, I had just had a set of awful issues with Pylons. In fact, I'm still having them, but let's not beat a dead horse.

I try to not gloss over those things I don't like about software that, overall, I enjoy using. Right now, for example, I'm adding by-month archives to this blog, and I'm having to do queries more advanced than my usual Object.objects.all() or Object.objects.get(attr=value). Sure enough, constructing queries with anything but this bare minimum of complexity gets ugly and magical fast with Django's ORM.

Dynamic Keyword Arguments?

This ugliness comes from the way Django's ORM handles different types of SQL queries. In SQLAlchemy, a like() function, for example, can be used to search for text in a field, as well as other selectors like in_, not_ and so on. In contrast, in Django's orm... you actually call Object.objects.get(fieldname__contains=value, fieldname__in="whatever"). Whoa.

Keyword arguments are a very useful and intuitive feature of Python. They allow you to cleanly allow the programmer to pass in variables if they vary from defaults, without creating overly verbose or repetitive interfaces for your functions1. Kwargs are a Good Thing. But, like most features, they can be abused when you expose too much cleverness to the developer.

And when you start asking your developers to call your functions with generated keyword arguments - in a particular format - as part of your public interface, well, I award you no points, and may God have mercy on your code.

And yes, there is a better way. SQLAlchemy's querying is just as expressive, but still Pythonic.

This is just part of a larger problem that I alluded to before: Django's ORM, while useful, and with a wonderful class definition syntax, is lacking important technical features, and will remain that way as long as Django uses an ORM developed for and by Django. It'll work fine for your run-of-the-mill blogging application, but is the Next Big Web Application going to be another blog engine? No, it's going to be an application that _pushes the limit of all available technology_. Good Enough today is Mediocre tomorrow.

The Django ORM Problem

So now Django has a problem. See, they have an ORM with a beautiful interface - for very basic things. But once you try to do the extraordinary with it, well, it's frustrating to say the least. Django's class models are so intuitive and easy to grasp that SQLAlchemy's expert-friendly interface looks positively enterprisey by comparison - and that's something Python programmers wisely shy away from.

So Django has it's users stuck on an interface that is wonderful, but an implementation that has fundamental issues. On the other hand, we have SQLAlchemy - an incredible amount of power, and with very good developers who show remarkable focus on good implementation - and yet an interface that most Django users (myself included) would find bewildering.

So what do they need? A delarative layer for SQLAlchemy. 2 And that'll be the subject of my next post.

  1. Need I say more? ↩

  2. No, Elixir isn't it. But that'll be the subject of my next post. And, of course, I'm ignoring the fact that Django has declared it's model API more-or-less stable for 1.0. But that's OK, here on the intarwebs we're allowed to ignore facts. ↩