#22474 closed Bug (fixed)
Bad migration detection in multiple database setup
| Reported by: | Claude Paroz | Owned by: | nobody |
|---|---|---|---|
| Component: | Migrations | Version: | 1.7-beta-1 |
| Severity: | Release blocker | Keywords: | |
| Cc: | Triage Stage: | Ready for checkin | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
While trying to play with migrations in contrib apps, I stumble upon test issues, and finally found out that the migration was only applied to the first database ('default'), because while setting the second test database ('other'), MigrationRecorder was querying the first (default) database to detect if the migration was applied or not.
Attachments (2)
Change History (9)
by , 11 years ago
| Attachment: | 22474-1.diff added |
|---|
comment:1 by , 11 years ago
| Needs tests: | set |
|---|
comment:2 by , 11 years ago
| Patch needs improvement: | set |
|---|
And just realized flush is a classmethod without access to self.connection :-/
comment:3 by , 11 years ago
| Needs tests: | unset |
|---|---|
| Patch needs improvement: | unset |
comment:4 by , 11 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
comment:5 by , 11 years ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
Might be worth factoring self.Migration.objects.using(self.connection.alias) into a property on the class? Otherwise, looks good.
comment:6 by , 11 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
Use the proper database to query for Migrations