> And I've found SQLAlchemy to be basically unusable unless you use the new 'declarative base' stuff, which looks suspiciously similar to... Django's ORM :)
I can relieve your suspicions as I never looked at Django's ORM at all when designing declarative. It's merely poking normal SQLAlchemy attributes, all of which existed before Django was ever released, onto a class. I can assure you active-record style class mapping is not an idea Django invented.
The same design pressure (to make the simple stuff easier) is at work in both cases. Much like, say, Bottle and Flask looking very similar.
The "basically unusable" is probably a little harsh, but I've never really understood the motivation behind some of SQLAlchemy's design decisions. eg. separating one class/table definition into interacting table, model and mapping classes makes no sense at least 99% of the time - that seems like something which should be hidden internally (but accessible if you really need it).
well if you read our docs you'll see that they're entirely in agreement with that. separate mapping/table design is called "classical mapping" and was years ago superceded by the declarative style. Update your sqlalchemy knowledge before commenting on it.
interestingly enough a ton of users still prefer the mappers/tables to be separate.
I can relieve your suspicions as I never looked at Django's ORM at all when designing declarative. It's merely poking normal SQLAlchemy attributes, all of which existed before Django was ever released, onto a class. I can assure you active-record style class mapping is not an idea Django invented.