I've been absent for the last couple months on the SQLObject mailing lists, and not doing any maintenance work. At some point I realized -- hey, I have a day job, and then I'm supposed to come home and work on this? I suppose every developer has had this feeling, especially when you lead a project that's, well, not in maintenance mode exactly, but at least it has a bunch of users, bug reports, newbie questions (which aren't so bad because they are easy) or worse the expert questions, which are always hard.
Anyway, at some point I decided to disengage until I could recommit. I didn't want to do a half-assed job, or more accurately I didn't want to feel guilty for not even doing that much. So I let it sit for a bit -- the code still worked, and there were other people to answer questions.
In the meantime I've started to use SQLObject in my work. Our use of Zope 2 is still a problem, since I'm not using SQLObject at all in that environment; I sometimes find myself thinking about creating a half-assed ORM in that environment (but maybe I should try Modeling; it might give me some ideas in the process, and it should certainly be better than Z SQL). Anyway, now that I'm using SQLObject in my job, I find it easier to work on it, even after hours. If I'm doing something just for my own enjoyment, a database wrapper won't be it. Databases are useful, but frankly they are not that interesting.
Hopefully I'll soon find my way back to FormEncode and Webware as well.
I've been having a good deal of fun mangling and managing with SQLObject, including perverting it to use Postgres table inheritance. I know, not portable at all but fun.
Lots of chatter about Ruby and "Rails" lately. Without knowing Ruby or looking too carefully at the Active Record API, it seems to me that SQLObject does more in some areas, perhaps a little less in others, but goes further in hitting the sweet spot which is - I think:
- Make it easy to do new projects where you have total control over schema
- Make it simple to adapt SQL Objects to an existing schema.
Its easier to use SQLObject than it is to use plain DBI access to tables, even if only using SQLObject for really simple minded stuff. It would be rather nice to take a great broom through it and make it oh-so-complete across all the supported platforms, or at least head down that road. Having used three different Python ORMs now, two fairly extensively and now getting there with SQLObject, I think your project ends up being closest to what is immediately usable for the new-to-Python or new-to-Python and DBI crowd.
Active Record and Ruby are starting to get some attention from disillusioned Java developers - they need to look around a little more.
I'm not giving up my whitespace in exchange for a bunch of end block closures!
I second Mike's comment about SQLObject's API. It was surprisingly simple to get my head around.