And give the dev the ability to switch out to a different database if needed. Thankfully, in Django it's just a config switch.
But for 99% of the business logic tests I write, sqlite is fine. Sure you might have an issue with Oracle, but for day to day stuff, sqlite is good enough.
That's because you are not using the power of postgresql.. (if you can test and run locally with sqlite).. are you using transactions, no? Because Django doesn't enforce them O_O
No I'm saying that if you mutate related models and didn't wrap them on a transaction it can leave you (if something fails) on an inconsistent dB state.. this is something it can't happen on sqla
Which is reasonable with sqalchemy because it operates at a lower level, where you manually handle sessions anyway. You don't do that in Django, by design. You can change commit behaviour if you want, though, and then you can just use transaction.atomic and still don't handle the session manually.
If you'd want atomic transactions for the whole Django project, you could just set the ATOMIC_REQUESTS flag in the settings.
The very best ORMs are not anywhere near as good at 'compiling' their abstractions into platform-specific SQL than your standard C/C++ compiler is at producing optimized platform-specific machine code. Part of the reason for this is that SQL is already at a high level of abstraction comparable to the ORMs themselves; the relationship between Python and SQL is not comparable to the relationship between Python and assembly (or C and assembly, etc.)
A better analogy than the language one: Your web app has to run on Firefox, Chrome, and... IE6 yay! You're not allowed to use any modern Javascript, or most of the API's you'd like to use.
Because being able to switch to IE6 at any point in development is more useful than any of those fancy-dancy API's, right?
If there was an ORM that dealt with everything but a flaky end of life database, sure start working on it.
But this is advocating picking one platform. Like creating Chrome-only JavaScript. I guess the nearest thing with Electron.
Yeah the analogies breakdown at some point.
I don't think anything is black-and-white. I just think the vast majority of Django apps are fine with Django's ORM. This article smacked of premature optimisation.
> I always get the feeling that people love ORMs because they don't want to learn SQL.
I suspect that's the problem. It's neither my feeling or my experience.
Every platform/language/OS/chip I know has annoyingly apparent problems. In my experience high-self-conidence-low-self-awareness folks are too keen to drop-level and 'make it right'. And love feeling how smart they are ('everyone who disagrees is obviously not as smart!) Too often 'smart-guys' cost more, long term. And I'm not ragging on you. That was me in my 20s. Embarrassingly.
Agree, at least for me, I don't discovered the sqlsuperpowers till I got inside it...
I would love to see some of this pretty clever orm migrations applied on a busy potgresql server.. with a bit of concurrency... :)
imagine hating working with databases so much you'd want to spin not being able to use modern databases amazing features as a "potential positive" just so you don't have to deal with them...
"Imagine hating databases" ... "just so you don't have to deal with them"
Do you normally respond to issues by trying to characterise people?
Imagine this fictional world where anyone that disagrees with me is incompetent.
In my experience, I think working with database specific functionality is like dropping to lower-level of code generally. Something I have done in ORM->Raw SQL and C->Assembly. There is a point where the price in development cost, testing development time, platform lock-in, reduced code reuse IP, subset of experienced programmers within the team/salaries/training, loss of access to future updates and bug fixes, and so on is worth it. But almost never in my experience. Almost but not entirely.
