#25647 closed Bug (fixed)
Regression with TEST MIRROR database migrations
| Reported by: | Gavin Wahl | Owned by: | Tim Graham |
|---|---|---|---|
| Component: | Testing framework | Version: | 1.9b1 |
| Severity: | Release blocker | Keywords: | |
| Cc: | Aymeric Augustin | Triage Stage: | Accepted |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description (last modified by )
I have a project with two databases: 'default' and 'logging', where logging is just an alias for default (to allow writing to logging while in a transaction in default). I have logging has 'TEST': {'MIRROR': 'default'}, and a database router that doesn't allow migrating on logging.
When running the tests, migrations randomly fail to run. This is because get_unique_databases stores all the aliases for a specific database in a set, and then setup_databases migrates on the 'first' one, despite sets not having a 'first' element. This randomly, based on hash randomization in python, picks either 'default' or 'logging' to be migrated. When 'logging' is migrated, all the migrations are no-ops because migrating is turned off for 'logging'.
I believe this is a regression introduced in [49eee8424].
Change History (8)
comment:1 by , 8 years ago
| Version: | 1.8 → 1.9b1 |
|---|
comment:2 by , 8 years ago
| Description: | modified (diff) |
|---|
comment:3 by , 8 years ago
| Cc: | added |
|---|
comment:4 by , 8 years ago
Well, aside from "sorry I must have messed up" and "I wish we could test this", I don't have much to say :-(
IIRC this commit was in the middle of a refactoring and cannot be easily reverted. I'll try to write a patch but I'm not sure when I'll find time for that.
comment:5 by , 8 years ago
| Owner: | changed from to |
|---|---|
| Severity: | Normal → Release blocker |
| Status: | new → assigned |
| Triage Stage: | Unreviewed → Accepted |
I'm looking into the issue in hopes of solving it before Monday's release candidate.
comment:6 by , 8 years ago
| Has patch: | set |
|---|
I don't know if we should try to consult database routers in this code at some point, but for now I took the conservative solution of reverting the original patch. It was a pretty clean revert. The original commit is part of this pull request. As far as I could tell, it's not actually important for Oracle support (at least for now, since we don't support parallel testing on Oracle).
Aymeric, could you provide input on this one?