Entries in "Django"

Quicker Cleveland RTA Schedule with Django

RTA

Since moving to Cleveland Heights, Sara and I have been taking the RTA to and from campus pretty often. The stop outside our apartment can get us there via the 9X or 7X, so we usually check those big tables before catching the bus. I thought it would be a big improvement if we could just have a little desktop widget that would say when the next bus on either route was coming.

But what's the fun in making such a simple widget if the backend powering it isn't generally useful? So I made a simple site that shows the bus schedules in a format more suited to our riding patterns. The plan is to have iCalendar feeds of the routes and stops, which the widget will read, while others can use the feeds however they prefer. For now the Superior & Mayfield and Mayfield & Euclid pages serve my needs.

This is after a couple days of hacking, so there are bugs, particularly in the early morning hours (due to weekday buses running until Saturday morning, for example). A trip planner would be nice too. One annoying limitation is that there isn't a list of all stops for every route that I can find. The 6 stops at Mayfield & Euclid, but it isn't listed in the abbreviated 6 schedule, so it won't show up there. Argh.

If the route you want isn't listed yet, just replace the 7X in http://exogen.case.edu/rta/route/7X with the route number and it'll fetch it from the RTA site.

Happy commuting...

Thinking about taking over the django-sqlalchemy branch

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.