On 2 mars 2013, at 15:50, Shai Berger <[email protected]> wrote: > There is an issue you seem to be ignoring: An "ORM Write" is, in many cases, > more than a single query against the backend. The most obvious example is > models with inheritance -- trying to do these with database-level autocommit > means that the code writes the two parts in separate transactions. I'm very > -1 > on this.
Yes, that's very important. Anssi raised this problem on IRC too. (I also heard that Django is currently broken in this regard; I didn't check.) > There are two alternatives I see -- one is to make sure that an ORM Write is > still a transaction (not database-level autocommit); the other is to > explicitly commit-unless-managed (or something equivalent) after every read > and raw-sql, as well as write. The plan is to ensure that ORM operations that may result in multiple queries are executed within a transaction. It's possible to start with a dumb implementation, ie. wrap all ORM writes in a transaction, and eventually get smarter, ie. determine if more than one query will be emitted. Even the dumb implementation will have better transactional properties than the status quo. In practice, that means adding support for savepoints to all backends, ripping off https://github.com/xof/xact — with permission from Christophe, which I haven't asked for yet — and wrapping ORM writes in this decorator. However, autocommit is a pre-requisite for adding savepoints to SQLite, because of the stdlib's braindead implementation of PEP 249. Hence, autocommit is part 1 of the plan, and improved transaction management is part 2. > BTW, how do you treat select-for-update, which currently makes sense in > "faked > autocommit" mode, but will stop making sense with the suggested change? I'm leaning towards not doing any magic and documenting this as a backwards incompatibility. Relying on Django's current pseudo-auto-commit is very fragile: qs = MyModel.objects.filter(…) qs.select_for_update(…) # what if someone introduces an unrelated ORM write here? qs.update(…) I hope developers already wrap their select_for_update calls and associated writes in transaction.commit_on_success, and it's a good thing to make it mandatory. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
