Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#17168 closed Cleanup/optimization (fixed)

Transaction middleware only creates transaction for default database

Reported by: david.winterbottom@… Owned by: codeinthehole
Component: Documentation Version: 1.3
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: no

Description

The current implementation of django.middleware.TransactionMiddleware does not create a transaction for each database defined in the DATABASES setting, only the one defined by DEFAULT_DB_ALIAS. You can see this quite clearly by reading the source of: -
https://code.djangoproject.com/browser/django/trunk/django/db/utils.py.

Shouldn't the middleware manage a transaction for each database defined in the DATABASES setting?

Happy to provide tests and patch if this makes sense - I just wanted to check this wasn't a design decision first. I did email the mailing list with this question but no responses received:

https://groups.google.com/group/django-developers/browse_thread/thread/bba4ee95676086e3/e76c7885db4c77f8?hl=en&lnk=gst&q=middleware+transaction#e76c7885db4c77f8

Attachments (1)

explain-about-multi-dbs.diff (702 bytes) - added by codeinthehole 3 years ago.
First draft of doc update

Download all attachments as: .zip

Change History (12)

comment:1 Changed 3 years ago by anonymous

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 3 years ago by aaugustin

  • Component changed from Database layer (models, ORM) to Documentation
  • Triage Stage changed from Unreviewed to Accepted
  • Type changed from Bug to Cleanup/optimization

Since we can't enforce transactional behavior across databases, it's more reasonable for the transaction middleware to manage only the default database. Otherwise, we'd risk creating unreasonable expectations.

Therefore, and in order to avoid a backwards incompatible change, I propose to document the current behavior (in topics/db/transactions.txt).

comment:3 follow-up: Changed 3 years ago by codeinthehole

That seems like the right solution to me. Would you like me to make the appropriate edits to the docs and send a patch? Or is there a different process for documentation writing?

comment:4 in reply to: ↑ 3 Changed 3 years ago by aaugustin

Replying to codeinthehole:

Would you like me to make the appropriate edits to the docs and send a patch?

Yes, that's the next step.

You can assign the ticket to yourself when you start working on it.

comment:5 Changed 3 years ago by codeinthehole

  • Owner changed from nobody to codeinthehole
  • Status changed from new to assigned

comment:6 Changed 3 years ago by codeinthehole

  • Needs documentation set

Changed 3 years ago by codeinthehole

First draft of doc update

comment:7 Changed 3 years ago by codeinthehole

  • Has patch set
  • Needs documentation unset
  • Resolution set to fixed
  • Status changed from assigned to closed

comment:8 Changed 3 years ago by kmtracey

  • Resolution fixed deleted
  • Status changed from closed to reopened

It's not fixed until a code or doc change has been checked into the repo.

comment:9 Changed 3 years ago by anonymous

Should the docs also clarify whether this transaction applies to the test database?

comment:10 Changed 3 years ago by Tim Graham <timograham@…>

  • Resolution set to fixed
  • Status changed from reopened to closed

In [5d81ad1af14ee3127b53f923687ed5c4e00329ee]:

Fixed #17168 - Noted TransactionMiddleware only works with "default" database alias.

Thanks codeinthehole for the draft patch.

comment:11 Changed 3 years ago by Tim Graham <timograham@…>

In [a89e76d15149c0758e6459d695ce60722cad7101]:

[1.4.X] Fixed #17168 - Noted TransactionMiddleware only works with "default" database alias.

Thanks codeinthehole for the draft patch.

Backport of 5d81ad1af1 from master

Note: See TracTickets for help on using tickets.
Back to Top