#9964: Transaction middleware closes the transaction only when it's marked as
dirty
---------------------------------------------------+------------------------
Reporter: ishirav | Owner:
mtredinnick
Status: assigned | Milestone: 1.3
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 shai):
Replying to [comment:22 seanc]:
> I would argue that this is more than a simple cosmetic bug
>
Has anyone argued otherwise?
>
> 3) Neither COMMIT or ROLLBACK will perform any better than the other.
See the following thread for some small details.
>
> http://www.mail-archive.com/pgsql-gene...@postgresql.org/msg60957.html
>
While this is an important data-point, PG isn't the only database engine
that should be considered. Just saying.
> One important catch to keep in mind is that SELECT can call functions
that modify tables. COMMITs will provide better "do what I expect"
behavior, but I would argue that users of functions that modify data
should be explicit in their COMMITs.
>
I would argue that in general, people who do this deserve whatever results
they get. If you're doing it for auditing (i.e. you need to register the
fact that a select has been executed), then you need to have the auditing
records committed whether the main transaction commits or rolls back. I
can see no other valid use-case for a table-modifying select.
>
> Based on what I've read in the thread above, adding three new versions
of the TransactionMiddleware appears to provide the easiest path forward.
"TransactionMiddlewareRollback," "TransactionMiddlewareCommit," and
"TransactionMiddlewareOpen". Copy TransactionMiddleware to
TransactionMiddlewareOpen and have TransactionMiddleware issue a warning
on startup that the developer should switch to Rollback or Commit (or Open
to preserve the current buggy functionality). In a future version, change
TransactionMiddleware to use TransactionMiddlewareRollback as the default
or just remove it all together. I'd rather see an explicit behavior
configured as a Middleware class vs. an entry in settings.py.
You'll need something similar for the decorators, and once it's not a one-
line-in-settings.py change, it's ugly.
I also repeat the observation that Middleware classes are activated in
settings.py. How, then, is the class selection an improvement over some
other setting?
--
Ticket URL: <http://code.djangoproject.com/ticket/9964#comment:23>
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-upda...@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.
