Ticket #369 (closed enhancement: wontfix)

Opened 6 years ago

Last modified 2 years ago

Specify database in migration class when using multiple databases

Reported by: agodfrey@… Owned by: andrew
Priority: minor Milestone: 0.7.1
Component: migrations Version: 0.7-pre
Keywords: multiple databases, django1.2 Cc:


I've been testing out the --database=name option for the migrate command and it works well. I'm using python fabric for automated deployment. My problem is that during deployment to the production server an automated process is used. At the time of deployment I would need to manually look at each migration to determine which database it is using which would mean all schema and data migrations would need to be done manually. My thought was to be able to specify the database to be used in the migration class similar to the no_dry_run attribute.

It would look something like:
Class Migration:

database = 'other_than_default'


This attribute could also be specified via the command line to populate it.
python manage.py schemamigration some_app schema_name --auto --database="some_other_db"

Then when running the migrate command each migration would be applied to the default database if nothing is specified or to the one specified per migration.

Change History

comment:1 Changed 6 years ago by andrew

  • Status changed from new to closed
  • Version set to 0.7-pre
  • Resolution set to wontfix
  • Milestone set to 0.7.1

This is essentially a request for more sophisticated support for MultiDB; this has already been pretty much decided in terms of how it will work (and it won't be like this, which is why I'm WONTFIXing it).

The support that we do come out with will be support for having different sets of migrations - one per database, usually - with different models in them. --auto will detect which models go where, by using the database router's allow_syncdb function, which Django already has, and do things roughly correctly.

This feature will be released in 0.7.1, so not in the almost-released 0.7; in the interim, you could look at using the SOUTH_MIGRATION_MODULES setting and more than one settings file to achieve the same result (albeit without --auto knowing what to do).

comment:2 Changed 6 years ago by andrew

I've made #370 as a ticket representing those changes, by the way.

comment:3 Changed 2 years ago by artem.rizhov@…

  • Status changed from closed to reopened
  • Resolution wontfix deleted

While #370 is not implemented during 4 years, maybe it makes sense to implement more simple alternative?

comment:4 Changed 2 years ago by andrew

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

Please don't reopen tickets. This feature will be implemented in the new Django migrations code and the resulting backport as South 2.

comment:5 Changed 2 years ago by artem.rizhov@…

I've published a snippet for those who can't wait for new Django migrations and South 2. https://gist.github.com/artemrizhov/7234995

Note: See TracTickets for help on using tickets.