Now that TurboGears has experimental support for SQLAlchemy, I need to provide SQLAlchemy-based alternatives to the SQLObject components of Visit Tracking and Identity.
Writing a SQLAlchemy Identity Provider won’t be a terribly difficult task, however, Visit didn’t include facility for abstracting the database access. But now it does via the VisitManager.
I’ve long been of the opinion that one of the few things that’s wrong with TurboGears is its reliance on SQLObject. While it’s nice to hear that a new version of SQLObject is in the works, I’m not confident the newer version will be much better than the older.
After an aborted attempt to create my own ORM, I’ve endorsed SQLAlchemy and committed to helping out — in my copious spare time.
Today marks an important milestone: You can now use SQLAlchemy in TurboGears.
I need to keep a closer eye on the tickets for Identity. There’s a really interesting ticket up there about changing the Identity predicates to use overloaded operators and it includes a note about any() and all(), which are new built-in functions which will make an appearance in Python 2.5.
On the one hand, I think it’s wrong to overload binary operators (&, | and ~) to mean boolean operators (and, or and not). Unfortunately, Python doesn’t allow overloading the standard boolean operators; so this practice has become pretty widespread.
I don’t like it and unless someone forces me to implement it, I’m not going to. (So there!)
My goal for any API I develop is to keep things simple. This is especially true for the TurboGears Identity framework, because it identity management and access control can be a pretty daunting concept for anyone to grasp.
Making the simple complicated is commonplace; making the complicated awesomely simple, that’s creativity.
— Charles Mingus
With all the talk about tagging and folksonomies (I hate that word), I encountered a discussion on Philipp Keller’s site about the database schemas behind tagging systems.