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.
Which doesn't detract from my argument. Since leaky abstractions are bad why on earth would you double or triple them, building another abstraction (ORM) on the first one (SQL)?
>There's nothing incompatible between using SQL for that 2% of cases and an ORM for the rest
For serious development you'll find it's not just "2% of cases". YMMV. And again, there is something incompatible: certain ORMS make it difficult or prevent it altogether, and even if they allow it you end with a hybrid ORM/SQL codebase.
>I don't think anyone's afraid of SQL
I've met plenty of people who do. Some even think it's alien, the same way some people wouldn't touch LISP syntax with a bargepole.
>but I sure as hell would be afraid of maintaining hundreds of plaintext SQL queries every time I add a new column
If you need to do that, then you're doing it wrong.
>All SQL implementations have ad-hoc additions that are platform-specific, and most ORMs work pretty damn well.
"Pretty damn well"? As in generating slow ass queries, needing 300 pages of documentation (I'm thinking of Hibernate) for stuff you can do in 5 minutes in SQL, etc?
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".
>This is BS. I have to touch a substantially larger amount of code when refactoring SQL than when touch ORM queries.
Have you even tried to understand what it says? You can take your SQL and use it in another language, or in the DB CLI etc. Your ORM code is tied to your original codebase. No using SQL Alchemy if you switch to Java.
>Seriously, have you even used a decent ORM?
I've used SQL Alchemy, Hibernate and Django's ORM.
Never found a decent one.
But I know that connect-the-dots, Visual Basic style developers swear by them.