Well, I've been getting back to SQLObject development a little lately. I realized there isn't a whole lot that needs to be done before an 0.7 release, so I'm trying to get everything ready for that.
First, I put up a new site design. It's just like the new Paste design but with different colors. I also added a blog where I plan to make note of SQLObject-related stuff. Incidentally there's also a Paste blog. There's a CSS related problem that I don't understand with wrapping on those pages; if anyone has ideas... I'm also trying to collect links to SQLObject-related articles and projects; comment here if you see something that is missing.
The big change in 0.7 will be the introduction of the .sqlmeta attribute that holds most of the metadata. This gives a formal public interface for introspection that has been missing for some time. I'm also starting a more formal deprecation process; 0.7 shouldn't break 0.6 code, but you'll start getting warnings. With a public, stable API for introspection I hope to rebuild bits and pieces of SQLObject using that API (and a couple other metaclass-related protocols I'll add after 0.7). No radical rewrites, just creating new structures to replace the old, even though they will live happily alongside the old pieces.
Besides lots of bug fixes (which were all applied by Oleg, so I haven't kept track of them at all) the other major feature is probably the as-yet-undocumented sqlobject-admin command-line management tool. It still has some serious rough edges, but I think it's got a lot of potential. It helps you create your tables, which is fine, but the more interesting feature is how it can track the deployed versions your database schema and apply updates.
Automatically updating a database is a Very Hard Problem. I think sqlobject-admin tackles the problem in a good, tool-based manner, avoiding any cleverness. You run sqlobject-admin record and it will save the SQL of all your tables (if it's any different from the last recorded version). If you add --edit then it creates an upgrade file and opens it in an editor; you'll have to give the statements for upgrading the database on your own (that's the Very Hard Problem if you try to do it automatically), but it will show you a diff of what's changed in this version which usually makes it trivial to write the SQL.
Then sqlobject-admin upgrade applies any upgrading SQL scripts to the database, based on a special table in the database that gives its current version.
Anyway, that's what's coming in 0.7. I mostly have to fix up and extend the documentation a bit, update the News file, fix a couple problems with sqlobject-admin, and then release. No heroic effort required, just some grunt work. Further news will go on that blog.
By the way, if you want to read new stuff on SQLObject then Leonard Richardson has an article at DeveloperWorks and I came upon this document at Canonical.
The wrapping on http://sqlobject.org/docs/interface.py.html and the other pages looks.. not good. Maybe it is the firefox beta I'm using? :-)
This new LEFTJOIN stuff in sqlbuiler looks neat, I haven't seen much reference to it yet. Fast joins that fit with sqlobject syntax will be nice :-)
The only other feature I miss is a non-hackish way to access the database directly and run custom queries, this sqlmeta refactoring may help with that.
# Justin
Oh, right, I forgot all about the SQLBuilder enhancements...
There's also a new sqlhub object for managing connections without passing arguments around.
What's the issue with the wrapping on the other pages? It's not perfect, but I didn't want the navigation menu to take up the entire left column as the loss of horizontal space is more of a problem with a long document. But there might be other artifacts getting through; floats are hard :(
# Ian Bicking
you can fix the wrapping by adding 'margin-left: 200px;' to the rule for div#body in style.css. (tested in firefox. may need minor adjustment for IE)
Any plans to support MSSQL Server in the future? Just curious as there doesn't seem to be a lot of support out there for MSSQL.
Thanks.
# Peter
Some people have put in some initial work, and I think it's in the repository. Proprietary databases are hard to support, and so far people interested in developing that support have tended to wander off. There is Sybase support, which should be similar to MSSQL due to their common ancestry. I personally wouldn't work on it unless there was something work-related requiring it (and if I'm involved in the technical decisions, I'd actively avoid MSSQL anyway); while I would help SQLObject support any open source database, even if I didn't use it, I put very little priority on integrating with proprietary software.
# Ian Bicking
> I'd actively avoid MSSQL...
> while I would help SQLObject support any open source database, even if I didn't use it, I put very little priority on integrating with proprietary software
I respect your objection to using MSSQL. I even agree with you to a point (PostgreSQL is great!), although MSSQL has some very nice features including extremely nice administration tools...but we won't get into that discussion.
Moving on... Can you see value in allowing people to use SQLObject by providing an easy way to connect to MSSQL? It certainly doesn't hurt SQLObject to have easy integration with MSSQL. I'd even argue that it will improve the market share of SQLObject to have that connector built in and ready to go. The last thing most developers want (or have the ability) to change when they are working on a database project is the persistence layer. That means that most people who are currently using MSSQL and looking for a Python ORM will pass over SQLObject because it doesn't work with MSSQL. You can hardly deny that Microsoft has a LOT of market share, which means that a lot of people won't be using SQLObject until there is an easy way to use it with MSSQL.
I'm not going to stop anyone. I'll even help, to some degree (maybe just a small one). But features like this need a champion, and I definitely won't be that champion.
# Ian Bicking
For an extensive discussion on some of the issues involved in programatically genertating schema upgrade scripts, see this thread from the PostgreSQL mailing list: http://archives.postgresql.org/pgsql-general/2005-06/msg00469.php
I've been diffing my dumped create scripts and creating upgrade scripts by hand as needed. Works ok, though I've got a pretty small database - less than 30 tables.