On: Surviving Django, if you care about databases

[airstrike]

> Django needs it because a web framework not tied to a single database vendor is more valuable than one tied to a specific one - and that's fair enough. But you don't: your web program, most likely than not, will not have to switch from one database to another

This is missing the forest for the trees.

Sure, my one app won't need to migrate from MySQL to Postgres a year down the road, but as a developer, I'd much rather be allowed to abstract away each vendor's idiosyncrasies and be able to focus on my Python code regardless of whether I'm using sqlite, PostgreSQL, MariaDB, MySQL, Oracle or even MS-SQL

[djrobstep → airstrike]

The idea that some library can abstract away database concerns to this extent is wishful thinking.

You inevitably need to understand the SQL that your ORM is generating and what the database is actually doing. Otherwise you're flying blind.

[TylerE → djrobstep]

Realistically what ends up happening is that the DB gets abstracted away to a painfully feature-free lowest common denominator.

[bastawhiz → TylerE]

Django handles this quite nicely. You get your basic lowest common denominator subset by default. If you want something more powerful, you can explicitly import a db-specific feature.

And for some features, you'll get a NotImplemented exception. In the ten years I've been using Django, I've only seen these a handful of times, and only when using SQLite.

[airstrike → djrobstep]

I never claim it replaces SQL entirely and that therefore users can "fly blind", as you put it. But the whole point of the ORM is to abstract away part of it

[scaryclam → airstrike]

It also misses a more common issue which is upgrading a DB. Teams might not switch from mysql to postgresql often, but I sure hope they're upgrading the db version from time to time.