Share Tweet Share





In recent months, I’ve been working on a lot of Django/PostgreSQL projects. Django works pretty well with Postgres, and on the whole I’m happy with it as a framework. For one thing, it’s pretty easy to get it out of the way when the framework and ORM become an obstacle rather than an aid. It also makes some sensible decisions about MVC organization, and it’s easy for a database geek to understand the Models structure. And it can be easily adapted to working with stored procedures and views, and (glory be) uses transactions. However, there are a few things which could make Django a better platform for data-centric applications, and I’m offering the list below as constructive criticism in hopes of influencing the development direction of Django. It’s likely that my company will contribute to a few of these items. Multiple Connection Support: Django should be able to support multiple connections, either to different databases or as different users. I understand that this is coming in 1.2. Allow the Use of Schema in Place of App Names: currently Django prefixes all table names with the “app name” resulting in table names like legacyauth_userpreference. This makes sense on databases with no schema support, but it would be great if, on Postgres, Oracle and other DBs with good schema support, Django would support replacing that “_” with a “.” so that we could use real schema. I realize that I’m asking that Django make its multi-DB support more sophisticated by having per-DB-platform configuration, but I strongly feel that’s where Django should go. Have Some Security Consciousness: currently a full-blown ORM Django application always connects as the database owner, all the time. This is an obvious security issue. Django could support connecting as the database owner when creating models, and as a less priveleged user at other times. Once there’s multi-connection support, of course. Leave Foreign Keys to the Database: currently if you’ve established an FK relationship in models.py, if you delete a parent record, Django walks the child records itself and deletes them. This is inefficient, error-prone, and leads to horrible deadlock situations. Leave FK deletion to the database via CASCADE — the database is built for it, and knows how to handle locking. Make Sure Abandoned Transactions Get Garbage-Collected: this may actually be more of a psycopg2 issue, but currently if the Django server gets overloaded, it abandons transactions without terminating them. This results in idle transactions running for up to 60 seconds on the database server, which in an already loaded application is meltdown-inducing. Don’t Retrieve Entire Rows to Get One Column: I know it’s useful to think of rows as objects, but I’ve seen Django use an ID to retrieve an entire 28-column row in order to get … the ID. This is wrong, and means that any database backing Django has to engineer carefully to avoid wide rows. Pulling data across the wire from the DB server is expensive, and one should pull the least data one can get away with. Thanks for listening … I wouldn’t make suggestions if I didn’t think Django was worth improving.