#9964: Transaction middleware closes the transaction only when it's marked as
dirty
---------------------------------------------------+------------------------
Reporter: ishirav | Owner:
mtredinnick
Status: assigned | Milestone: 1.2
Component: Database layer (models, ORM) | Version: 1.0-beta-1
Resolution: | Keywords:
transactions
Stage: Accepted | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------------+------------------------
Changes (by shai):
* cc: shai (added)
Comment:
Replying to [comment:17 russellm]:
>
> The current patch proposes to preserve the current behavior, as well as
adding a new behavior that implements a new behavior. However, this isn't
an area of API where the end user should be required to make a choice at
all - it should Just Work (tm). The only users that will care about the
different behavior are those optimizing for uber-speed, and for those
users we have extensive manual controls over transactions.
>
I agree, and I've set the defaults accordingly. The only reason I made the
choice user-visible was because I could see no other way to make it also
backwards-compatible -- to avoid changing the behavior under the feet of
existing projects. This is the sort of change that is bound to break some
user code; in this case, you essentially argue that the user should fix
their code or avoid upgrading, and I was trying to offer a smoother path.
> Replying to [comment:16 shai]:
> > This I also find confusing, as almost everything that is non-trivial
here is intended to keep the current behavior available for people who
need it (and in fact, keep it through the upgrade for existing projects).
Perhaps I misunderstand, but it seems like you are trying to decide on the
always-close-transaction issue, when the patch jumps through hoops in
order to defer this very decision -- to users for now, and to the future
in general.
>
> Deciding to push the decision to the user isn't a decision at all. (...)
We want to make a decision, and make sure it is the right one.
>
I mis-represented my intentions. There is a difference between "push the
decision to the user" and "make a decision but allow the user to
override"; I was trying to do the second. The decision I made was "no
change for existing projects, always commit for new ones". Allowing
override was, indeed, intended to limit the costs of a "wrong" decision (I
am pretty sure I made the right choice in general, but that might not be
right for some users).
Further, I believe these arguments will continue to hold after a more
thorough revision. We will still want backward-compatibility, and we will
still want the decision to be overridable. Granted, we might find better
ways to achieve these goals; granted, it makes sense to become more
confident of the decision; and granted, it can all wait to 1.2.
> > In this case, would you consider documentation patches (as proposed in
#9919)?
>
> Agreed, we probably should add some docs for this. (...) I'll reopen the
ticket, but a new patch will be required.
I'll try to provide a patch in the next few days, if nobody beats me to it
:-)
Thanks,
Shai.
--
Ticket URL: <http://code.djangoproject.com/ticket/9964#comment:18>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
