For the past couple weeks I've been telling myself that I'm the guy who could make the sqlalchemy branch a viable option. I think I'm familiar enough with both django.db (after my shot at Merquery and hunting down bugs from Trac) and SQLAlchemy (after modelling and remodelling inheritable, multilingual, revisionable tables a few times — an excellent way to far surpass any beginner's material in a matter of days) to be able to pull it off.

I talked to Robin Munn (the original maintainer) at PyCon and he is ready to hand it off to someone. I also spent time at PyCon dissecting the metaclasses used by Django, Elixir, and ActiveMapper to find out how they're different and why. Still not clear on the 'why' part, but I think I know enough to give it a go.

So, knowing very little about what Robin's already accomplished, my approach would look like:

  • Start a django.contrib.sqlalchemy.models.Model that would serve as a drop-in replacement for django.db.models.Model, as Adrian first suggested.
  • Almost all methods and classes used by this Model would be completely from scratch. There will be some opportunities for reuse, but I would much rather have something that does everything The SQLAlchemy Way. Don't even look at the django.db code unless it's clear that it solves a problem that SQLAlchemy doesn't, or resolves an undocumented feature.
  • Reimplement all of Django's fancy fields as custom SQLAlchemy types. This is theoretically a chance for reuse, but this part is trivially easy compared to making a model with the same QuerySet semantics. These types wouldn't support any of the oldforms stuff that the current fields do, since oldforms would likely be dead by the time this is finished.
  • Use SelectResults as a base for QuerySet, but use django__joins and 'strings' instead of Quoted.c.column objects where appropraite.
  • Totally ignore the undocumented API (like _meta) until the documented API works.

I was bored on the flight back from PyCon and started writing some notes on a napkin mapping Django's Model features to SQLAlchemy's syntax. I don't think it's a problem that requires solving any super hard problems, just lots of careful coding (to keep it clean).

So, will I be the one to do it? I'm not sure yet. I'll be spending a lot of time working on Pagoda, and already have a hard time maintaining geopy and other projects, which people often email me about. Maybe if I spend a weekend totally focused on integrating Django and SQLAlchemy, I'll come up with something that other people can contribute pieces to without having to completely understand the mapper magic.