3 ms·
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 i
by jordic 6y ago
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
- VWWHFSfQ 6y agoThen wrap the things that you want to run in a transaction.atomic. Is there something I'm missing?
- jordic 6y agoThat's the thing, you need to explicitly run on a transaction.atomic, with sqlalchemy, that's something that just works..
- bildung 6y agoWhich 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.
- jordic 6y agoThat's a nice feature, when landed it?
- bildung 6y agoAt least in Django 1.6 from 2014, couldn't find older docs.
- jordic 6y agoDoes still django lacks a connection pooling? If I'm not wrong sometime ago I saw people using the sqlalchemy pool on Django projects.
- bildung 6y agoNot since Django 1.6 from 2014.