> Here's a gem from Django's 1.6 release notes (that somebody praised its ORM in the comments above): "The Model.save() method now tries to directly UPDATE the

> Here's a gem from Django's 1.6 release notes (that somebody praised its ORM in the comments above): "The Model.save() method now tries to directly UPDATE the database if the instance has a primary key value. Previously SELECT was performed to determine if UPDATE or INSERT were needed" I see nothing wrong with this; almost all tables have automatic sequences for PK insertion. The proper idiom for creating a new instances is the model.objects.create() method, and save() supports the force_insert argument. This is a valid optimization and reflects the use case of people who are using the framework. I've been developing web apps for over half a decade, some of them pretty massive, most for regular businesses. The number of times I have needed to drop to SQL I can count with my hands outside of the limited domain of reporting. If you need to use SQL for regular old CRUD behavior, either your models are not being properly normalized or you're using a shitty ORM, and neither SQLAlchemy nor Django are bad ORMs. If your problem is that your domain object is spread across 15 tables and you actually need all those joins, there's always methods that invoke the necessary SQL and return the encapsulated objects, but like I said, you have bigger problems there than worrying about your query abstractions.