As I noted in my other reply, the two projects take different approaches, which are suited to different styles of development.
SQLAlchemy puts emphasis on the "SQL". It wants to expose every capability of your database and every feature of its SQL dialect, and is heavily oriented around thinking in SQL first and then working your way back to live objects in code.
Django puts emphasis on the "object" side of object-relational mapping; it doesn't aim to be a comprehensive API to your database (since you can just write SQL for that), and moves practically all of the design and interaction up into the Python code layer, then working your way down to the DB as needed.
Or, more succinctly:
* SQLAlchemy: "I have a database and want to interact with it through Python objects".
* Django: "I have Python objects, and would like to use a database as a store for them."
Neither one is objectively the "right" or "wrong" way to approach this, IMHO.
I think what he wants is instead of defining a table that a model maps to he could also just definea SQL query to select from. This is somewhat possible with Django 1.1 if you use a DB level view and unmanaged models.
Model validation should have been there from day one. Well thats what us Domain-Driven-Design advocates push.
SQLAlchemy is way more powerful and flexible. Scan the SQLAlchemy documentation for examples. Particularly storing nested structures and support for inheritance (which is broken in Django).
support for inheritance (which is broken in Django)
Django's ORM supports:
* Multi-table inheritance (just subclass and do stuff).
* Abstract parent classes (which get you most use cases for single-table inheritance).
* Pure-Python inheritance (via proxy models).
So I'm not sure how that's "broken".
But it's also worth noting that Django's ORM and SQLAlchemy approach the problem of ORM from opposite directions: Django starts at the object layer and works back to SQL, while SQLAlchemy starts at the SQL layer and works back to objects. Both have advantages and disadvantages, and both have their use cases.
In single table inhertance, any leaf node from the inheritance graph cannot solely contain a relation to another object. It has to be on the abstract base or the ORM dies when building inserts for other leaf nodes. That leaves you to implement any business constraints on the model, but there is no model validation so it gets shifted into the controllers (or views as they call them).
Perhaps I'm misunderstanding you, but I regularly use abstract classes with subclasses which add relationships to other things, and I've not seen this problem.
