Opened 12 months ago

Closed 12 months ago

Last modified 12 months ago

#23089 closed Bug (fixed)

manage.py flush --database=custom uses wrong transaction

Reported by: aigarius@… Owned by: nobody
Component: Core (Management commands) Version: 1.6
Severity: Release blocker Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

This is a regression from 1.5

If a non-default database is passed to flush management command, it still starts a transaction on 'default' database. This can be easily seen by setting 'default' database settings to an empty dictionary.

This is still in branches 1.6 and 1.7, but apparently fixed in master with commit 753a22a6352638b7df55176584795ac8c5d4232c

Change History (6)

comment:1 Changed 12 months ago by timo

  • Component changed from Uncategorized to Core (Management commands)
  • Easy pickings unset
  • Has patch set
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Severity changed from Normal to Release blocker
  • Triage Stage changed from Unreviewed to Accepted
  • Type changed from Uncategorized to Bug

Aymeric, can we just add 1.6.6 release notes and backport that commit?

comment:2 Changed 12 months ago by aaugustin

Indeed, the regression was introduced in ba5138b1c0253fcf390b7509ad7b954117b3be88, which replaces transaction.commit/rollback_unless_managed(using=db) with transaction.commit_on_success_unless_managed().

I should have backported the fix. At the time it seemed minor and I didn't check whether it was a regression.

Since the biggest part is the release notes, I would really appreciate if you can take care of that. Of course, if you have other priorities, I'll fix my own mess ;-)

comment:3 Changed 12 months ago by Tim Graham <timograham@…>

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

In 5ca82ff71baa9d749c98ef68e8f8814cf7afcf5d:

[1.7.x] Fixed #23089 -- Fixed transaction handling in two management commands.

Previously, when createcachetable and flush operated on non-default
databases, they weren't atomic.

Backport of 753a22a635 from master

comment:4 Changed 12 months ago by Tim Graham <timograham@…>

In 2a97db33a79c0be179b5bc35860400287f1ae26a:

[1.7.x] Avoided transactional DDL on castrated databases.

Fixed a test failure that appeared after 753a22a6, although the bug
existed before that commit.

Refs #22308 and #23089.

Backport of 0757e0f30d from master

comment:5 Changed 12 months ago by Tim Graham <timograham@…>

In 83098dccdf3172302cde54e11c36050c1d83f996:

[1.6.x] Fixed #23089 -- Fixed transaction handling in two management commands.

Previously, when createcachetable and flush operated on non-default
databases, they weren't atomic.

Also avoided transactional DDL and transactional truncates on databases
that don't support them (refs #22308).

Backport of 753a22a635, 0757e0f30d, and 6877a9d415 from master

comment:6 Changed 12 months ago by Tim Graham <timograham@…>

In bb395a15ba16cc3ae223265afb69ec95f0f78855:

Forward ported release notes for refs #23089.

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