#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 |
---------------------------------------------------+------------------------
Comment (by russellm):
Replying to [comment:16 shai]:
> Hi,
> > having a user-space setting to determine transaction behavior is a
non-starter.
> Could you please elaborate on this a little? I find it confusing, as the
setting activating the transaction middleware (as all middlewares) is in
the same space as the setting proposed in the patch.
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.
> > From a design perspective, there are some subtle tradeoffs that need
to be considered here, including weighing the cost/benefit of "always
commit",
> > and ensuring that manual transaction control will continue to work for
those that need every last nanosecond of performance.
> 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. More
control knobs doesn't necessarily imply better software. Part of the job
of a framework is to eliminate some decisions to make sure that things
always work as expected. We want to make a decision, and make sure it is
the right one. Since this is a bit of an edge case, and there is a
reasonable workaround, we're willing to defer that decision until we know
we will get it right.
> > On the flipside - the existing behavior works, as long as you
understand what "works" means.
>
> In this case, would you consider documentation patches (as proposed in
#9919)?
Agreed, we probably should add some docs for this. The patch on #9919
doesn't really do the job at the moment. To my mind, it makes a lot of
unnecessary changes, and only gives a marginal improvement on the one area
that the ticket should be addressing. I'll reopen the ticket, but a new
patch will be required.
--
Ticket URL: <http://code.djangoproject.com/ticket/9964#comment:17>
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 django-updates@googlegroups.com
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
