On 5 mars 2013, at 02:28, Shai Berger <s...@platonix.com> wrote:
> This is just a half-baked idea; I suspect those of you who are more well-
> versed in the current implementation of transaction management, and who put
> some thought into this, may be able to shoot it down easily. But here goes.
>
> Basically, transaction management reacts to user commands by doing either or
> both of two things: Issuing database commands ("begin tran", "savepoint x",
> "rollbak to x" etc), and changing its own internal state (e.g. marking the
> transaction as dirty, puhsing a new transactional level on a stack). There is
> a limited set of relevant user command classes -- explicit-enter-transaction,
> ORM-read, begin-ORM-write, end-ORM-write, etc.
That's almost correct; I see one possible pain point. When autocommit is off,
transactions are automatically started and that makes it difficult for Django to
track what's going on. In other word, there's no explicit "begin-ORM-read"
hook in the current code.
The dirty flag theoretically carries this information, but Anssi's recent work
in
this area show that it isn't entirely reliable nor sufficiently well defined.
(It isn't
clear whether reads are intended to make the connection dirty; they should.)
Knowing exactly when a transaction is in progress or not is one of my reasons
for preferring autocommit.
> The selection of state-changes and transaction-commands that are executed in
> response to user-commands is, in essence, a transaction-management policy --
> and there can be more than one of those in the code base, to be selected by a
> setting. Say, transaction_bc (for "Backwards Compatible") which does
> autocommit the way it is today, and transaction_ad (for "Autocommit at
> Database level") which does the right thing.
To provide a transition path, both APIs must be usable in parallel, at least to
some extent. A hard switch from transaction_bc to transaction_ad would make
it very difficult to update codebases to take advantage of the new APIs,
especially if they use third-party libraries that haven't been updated yet.
> If this can be done, then I think the proper way to handle the change is:
>
> Django 1.6 -- the default is transaction_bc, the default project template
> selects transaction_ad. Further, transaction_bc raises a deprecation warning
> whenever it sees an ORM-read followed by an ORM-write in an automatic
> transaction when it knows the transaction isolation level is >= repeatable
> read.
>
> Django 1.7 -- the default is transaction_ad, transaction_bc still available
> but raises deprecation warning whenever it is used (or at least whenever its
> autocommit is used).
>
> Django 1.8 -- transaction_bc removed.
In practice, this would mean:
- Define "hook points" that are a superset the old and the new APIs.
- Re-implement the current transaction management with these "hook points"
(hard, because the intended behavior of the dirty flag isn't clear).
- Implement the new transaction management with these "hook points"
(hard, because that prevents using Python's context manager abstraction,
which maps exactly to atomic blocks and guarantees that the exit method
is always called).
- Add checks to prevent invalid operations when mixing the old and new APIs,
this is extremely difficult to get right when there are many hook points.
- Provide simple guidelines on how the old and new APIs may be mixed.
- Ensure that the old API can be trivially removed, because the author of the
new code may not be there in two years.
This looks possible, but not in the amount of time I'm able to spend
volunteering for Django. If someone wants to implement this, I'll put my
branch on hold. Otherwise, I'll propose it for inclusion into core.
--
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
