Hacker News Reader

Comment by VWWHFSfQ | Hacker News Reader

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

View on HN

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

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

That's a nice feature, when landed it?

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

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

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

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

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.

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.

Reply on news.ycombinator.com