I came here to post essentially this exact comment. Give me Django with only routing, middleware, the admin panel, and the ORM and I'd be happy. The time I've saved because of these things so I'm shipping code and not writing SQL by hand is astounding. I've made the decision to use Python and Django over other languages and frameworks solely because of the ORM.

I honestly can't think of a single other piece of software that has actively saved me as much time.

> Give me Django with only routing, middleware, the admin panel, and the ORM and I'd be happy.

Very much this. I tend to lean towards Flask for building simple APIs. I think it's easier and faster to start a project and get something done.

But I always end up missing the admin features and the far superior ORM, and always regret midway that I did not use Django instead.

> the ability to swap out PostgreSQL for SQLite on smaller projects without having anything break is a feature I've relied on several times

Absolutely. Take the extra minute to add a natural key to your Django models and now you can do amazing things like dumpdata from your Prod or Staging database and then loaddata into your local sqlite database for dev. I've never had to run Postgres on my laptop for developing. As long as your CI tests use your production database server type then you don't have to worry about subtle differences between developing locally with sqlite and deploying on another RDMS.

That's really a so bad practice, a big code smell.. how you test all the dB logic, with a different dB? Constraints, indexes, tsvs..

With CI that tests both, and a dev team that runs a mixture of both.

Also Django abstracts the differences away well enough that we've never noticed meaningful differences that aren't already well documented.

> As long as your CI tests use your production database server type

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

What do you mean Django doesn't enforce them? Are you saying that transaction.atomic doesn't actually run in an atomic transaction?

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

Then wrap the things that you want to run in a transaction.atomic. Is there something I'm missing?

That's the thing, you need to explicitly run on a transaction.atomic, with sqlalchemy, that's something that just works..

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.

Does still django lacks a connection pooling? If I'm not wrong sometime ago I saw people using the sqlalchemy pool on Django projects.

Not since Django 1.6 from 2014.

That's a nice feature, when landed it?

At least in Django 1.6 from 2014, couldn't find older docs.

> That's because you are not using the power of postgresql...

Isn't that a potential positive?

I mean, yeah, and those darn programmers with their 'platform independent languages'. Why are you not using the power of assembly?

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.)

No, it's really not.

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?

Meh. All analogies are partial.

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.

Because if you do learn some SQL, then the problems with ORMs become annoyingly apparent.

I agree that most Django coders will be fine with the ORM. I guess I don't see that as a good thing, though.

> 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.

hehe, I'm in my 50's and have been doing this for >25 years. I still don't know where that line is

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.

If people had the same opinion when it came to web browsers we'd be in a pretty sorry state.

Are you talking about databases or decibels?

Haha, dB = database. My android keyboard is trolling me :/

This is absolutely true, especially if the dev environment believes that sqlite should be a first class citizen during development of unit tests.

If you'll forgive a rather insubstantial ramble about a pet-peeve of mine:

> many junior developers who don't know SQL

Are you really a web developer if you don't even know SQL? Sounds more like an apprentice. You wouldn't call yourself a junior Japanese translator if you didn't speak Japanese. SQL is a basic competency, not an advanced specialist skill.

This sounds like gatekeeping to me. Web development is a huge and rapidly expanding industry. You don't need (in fact, cannot) be an expert in all areas.

I've been a web developer for quite a few years now. Mostly front end but I do use Django as well.

I also do know some SQL so I guess I pass your arbitrary test. However, I can count the number of times I've used SQL in the last five years on one hand, and in each case it was something simple like create a role/database, and I had to Google the commands anyway due to a lack of practice.

> This sounds like gatekeeping to me

Not really. It isn't right that the software industry use the same title for both an untrained dabbler and for a CS graduate with a year of industry experience. The former is not a developer, they're a student, or an apprentice. The latter has several years of relevant formal education but only a little industry experience.

'Traditional' engineering fields have legally protected terms like Chartered Engineer. I'm not suggesting software development need be that rigid, but I don't think it makes sense to be so inclusive with a title like 'developer' that it tells the reader almost nothing about the person's level of competence.

Legally protected terms aren't necessary for this. If you call yourself a junior Japanese translator but you don't speak Japanese, you'll be laughed out of the room by real translators. That's as it should be.

> I had to Google the commands anyway due to a lack of practice

But your understanding of the underlying concepts (i.e. the relational model) was still there, and that's no small thing. Familiarity with syntax isn't really the point.

It's not really gatekeeping.

If you're doing any kind of backend work, you need to know how your persistence layer works. You don't need to be an expert, but you need to realize the implications of what you're doing with the ORM. You need to be able to diagnose issues with your database.

There is a grey area between 'don't know' and 'expert'. and what the if someone says it's bad that jr devs don't know something, it doesn't mean they need to be an expert.

frontend don't really need to know, but most backends talk to an SQL DB so I'd agree.

That said, what does "web developer" mean relative to those?

One of the things I've had trouble is that sqlalchemy also supports cross db but not completely (I never figured how to do date diff that works between postgres and sqlite). Does django orm help with that? And have you come across any flask+django ORM repos you can point to ?

Here's an example with Flask+Django ORM: https://gist.github.com/ChaosJohn/3842014035353d11591ec82f88...

Absolute second this

This is more "how to replace your car's stock transmission and cluch for dubious benefits and higher costs"

Django works fine out of the box. The example of "needless migrations" are corner cases more than anything and it's fine to have them. It works. They might be useless but if they're correct in the end, that's fine. DB migration is the one of the last places where I will look for performance over risking correctness.

And if you really need performance in one specific complex query, Django lets you do raw SQL queries just fine. Number of times I saw this being actually needed (in a big project): One.

The Django ORM is excellent as long as you stick to the well-trodden path. But if you want to squeeze every ounce of performance or you know that the execution plan a query generates is not the best or it's not using the right indexes, it's like wearing shackles.

SQLAlchemy on the other hand makes it very easy to do exactly what you need, without even having to drop to writing raw SQL. The way the ORM and the core are structured is the perfect balance of abstraction and control.

I'll agree that the Django ORM isn't very good once your queries get moderately complex. But I have been underwhelmed by SQLalchemy having tried it recently. It's not intuitive compared to Django's and in the end for complex query I just ended up in raw SQL anyway - as I would have in Django's ORM.

A lot of people rant about SQL alchemy. I have used it recently and it isn't anywhere close to Django's ORM for ease of use.