Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com