Hi Florian and everybody,
On Sunday 03 March 2013, Florian Apolloner wrote:
> On Sunday, March 3, 2013 12:27:47 AM UTC+1, Shai Berger wrote:
> > > I also believe that it beats the alternative — namely, live with the
> > >
> > > current behavior forever.
> >
> > I sincerely hope [...] that there's a way to implement the new behavior
> > side-by-side with the old one. There usually is.
>
> Can you describe how an alternative in this case would look like? I
> personally can't think of any sensible one.
>
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.
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.
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.
Hope this makes sense,
Shai.
--
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.
