Ticket #73 (closed enhancement: fixed)

Opened 6 years ago

Last modified 5 years ago

ability to specify separate directory for storing migrations

Reported by: chris.leemesser@… Owned by: andrew
Priority: major Milestone: 0.7
Component: commands Version: 0.3
Keywords: Cc:

Description

The placement of individual files in the migrations/ directory works well for individual applications running on a site. But, some of my apps are written as re-useable apps and it appears inappropriate to place their migrations with them---especially as some are related to other applications which may not always be present.

It would be useful to be able to specify a directory for a set of migrations that would be specific for that site.

Change History

comment:1 Changed 6 years ago by andrew

  • Status changed from new to accepted
  • Version set to 0.3
  • Milestone set to The Future

The whole idea about having migrations with apps is that they're meant to be tied to that app and that app alone. If you need other apps to have migrations, you make them in that app's directories, and if you need to use dependencies to make them apply in the correct order.

Apart from that, it's a reasonable request, although it'll require some tweaking to the module find/loading functions.

comment:2 Changed 6 years ago by peschler

+1 for this feature.

I just released the first version of a translation app for dynamic content which can be found here: http://code.google.com/p/django-modeltranslation/

The point is that when using reusable/pluggable apps the translations are project-specific, i.e. there are projects which use an app without translations and another project uses the same app with translations. My modeltranslation app makes this possible - unfortunately it is thus incompatible with south right now.

Adding the ability to "specify a directory for a set of migrations that would be specific for that site" would solve this problem.

comment:3 follow-up: ↓ 4 Changed 6 years ago by andrew

  • Milestone changed from The Future to 0.5

So, if I get this correct, the app slings in a few extra columns to each model, and so using it on an app essentially makes its schema, and thus migrations, different to a non-translated version of the same app?

That seems more like a case of needing either an extra migration on the end of the current lot (if you've downloaded the app from elsewhere) or having your own set (if you've made said app from scratch).

Still, the use cases for this seem to be mounting, so I'll slate it for inclusion in the next release.

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

Replying to andrew:

So, if I get this correct, the app slings in a few extra columns to each model, and so using it on an app essentially makes its schema, and thus migrations, different to a non-translated version of the same app?

Yepp, that is exactly the way it works.

That seems more like a case of needing either an extra migration on the end of the current lot (if you've downloaded the app from elsewhere) or having your own set (if you've made said app from scratch).

This would be another solution.

Still, the use cases for this seem to be mounting, so I'll slate it for inclusion in the next release.

Sounds good ;)

comment:5 Changed 6 years ago by andrew

  • Milestone changed from 0.5 to 0.6

Hmm, I'm going to have to bump this to 0.6 so I can get 0.5 out in reasonable time - it's going to involve quite a lot of changes to migration.py, and I don't want to risk the bugs.

comment:6 Changed 6 years ago by andrew

  • Status changed from accepted to assigned

comment:7 Changed 5 years ago by andrew

  • Milestone changed from 0.6 to 0.7

Bumping again to 0.7! It'll get done eventually, but we have to wait till after the pending migration engine rewrite that's already half done.

comment:8 Changed 5 years ago by andrew

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

This was implemented in [41fc76e83a19].

Note: See TracTickets for help on using tickets.