Quite some time ago, Daniel Savard wrote an extension to SQLObject to allow something closer to traditional inheritance. SQLObject already supports inheritance, but it's not what people typically expect, because it just clones a table instead of creating something that looks like a subtable. You can read the description of the patch for the details.
I've meant to respond to the patch for a long time, but I couldn't quite put my finger on what troubled me about it. But I've kind of decided: SQLObject isn't a way to persist your objects in a database. It's not an object->relational database mapper. It's a relational->object mapper, a way to model your relational database as objects. You aren't meant to forget there's a database. It isn't magical, it isn't transparent, and I don't want it to be. If you want transparent, use the ZODB, that's what it's meant for. Or use something like APE or Active Storage if you want a RDBMS backend to a object database. An RDBMS is a viable backend for that kind of work, but the result shouldn't be confused with relational modeling.
I think people should use an RDBMS for its advantages, and there are quite a few advantages. Being object oriented isn't one of them. It's probably not surprising that object oriented extensions to RDBMS systems aren't that popular. PostgreSQL has several such extensions, but I've never used them, nor seen them used in any project I've worked on. They seem like a novelty, an idea that seemed useful but didn't pan out. So I'd rather avoid the whole thing in SQLObject; certainly there is a lot of room for improvement where SQLObject could better model relations, but inheritance isn't one of them.
Spot on, as usual, Ian. You've summed up my philosophy on persistence much more elegantly and succintly than I have ever done.
The only thing I can add is this post http://www.halfcooked.com/mt/archives/000685.html where I link to an interesting essay by Tom Kyte, a well known Oracle guru, and commentary on it by myself and VS Babu.
Ian, I'm an amature SQLObject user and I generally agree with what you're saying, but I would add that in the case of subclasses, it would be nice if the supeclass could find subclass instances. Say, for instance, I have this kind of structure:
- class Server(SQLObject):
- ...
- class NameServer(Server):
- ...
- class WebServer(Server):
- ...
- class FileServer(Server):
- ...
Although the relational way to do this may be to structure one server table with server-type as a foreign key, if you're overloading your SQLObjects with methods appropriate for various kinds of servers, that kind of structure can be inconvenient:
- class FileServer(Server):
- def storeFile(...):
- ...
The way SQLObject creates tables for this makes sense, it's a poor relational model and if I want a way to grab all Server objects based on some criteria, it's troublesome. Of course, you can break up your model into smaller subclasses and tables, but in doing so I think you tend to lose what makes SQLObject so great, its simplicity and the resultingly simple models.
Having said all that, I'm not sure what the solution is or whether I think subtables are a good idea. It's been a while since I tinkered with PostgreSQL's Object-Relational notions, but I remember them being quite limited. Is there a way you could add some methods to superclasses for gathering subclass objects?
-Ken
A polymorphic join would be useful, certainly. This way a common server table could indicate the ID and table name that contains other information (i.e., DNS, web, or file information). There's also other ways to handle this relationally. Some of those techniques will require enhancements to SQLObject (though many of them are quite reasonable to implement in an ad hoc manner).