Hey Carl. Missed you so very much at DjangoCon. :-) > I'm not sure why the mezzanine docs don't mention using the SOUTH_MIGRATION_MODULES setting (or Django 1.7 equivalent MIGRATION_MODULES) to override the location of the mezzanine app's migrations to a package in your project, where you can freely add custom migrations without modifying mezzanine code.
While I don't want to speak for Mezzanine (and, frankly, am not crazy about their approach to field injection in the first place), I surmise that they want to be able to both ship their own migrations (when their models change) and allow their users to add their own migrations (for injecting fields). As I say, I don't love the solution, but I do see its advantages over merely providing a mixin, as they have a relationship structure of their own between their models that they want to maintain. You say that it's a reasonable tradeoff; I don't think I agree. For Django's part, I'm not convinced that, without exception, migrations for a particular model belong in the same app as that model. I think there are reasonable times to place them elsewhere, and this is one of them. Another is an occasion in which an organization has its own internal apps and runs versions of its project without and without a particular app. If that app requires an incoming ForeignKey from a model in a different app, that migration is ideally only implied in the presence of the target app. > I don't see any monkeypatch there, just subclassing, which is not the same > thing. I'd say that looks like a very nice solution to the problem. The level of "fiddling with internals" required seems roughly proportional to the peculiarity of the use case; I doubt you'll find anything better (other than perhaps avoiding the problem entirely by using MIGRATION_MODULES). I was unclear: What I meant was that a potential solution within the Mezzanine codebase is a monkeypatch which changes the state_forwards method at runtime to comport with the subclass example that I've provided. My question (which at this point probably belongs more on dev than here) is: Which is the most Djangoic approach: 1) Modify the Mezzanine docs to encourage users to take their own action, such as A) using MIGRATION_MODULES or B) manually editing migrations and subclassing the operation in question as I've done 2) Adding a monkeypatch to Mezzanine which automates solution 1B above (ie, a function that takes an Operation object and returns a OperationOnAnotherApp object) 3) Providing a solution in Django for migrating a model from an app other than that model's home On 11/01/2014 09:16 PM, Carl Meyer wrote: > Hi jMyles, > > On 11/01/2014 04:35 PM, jMyles Holmes wrote: >> Using Django 1.7, how can the user perform a migration operation (say, >> AddField) on an app other than the app in which the migration lives? >> >> Here's the use case: >> >> Mezzanine lets you inject fields on its own stock models using the >> EXTRA_MODEL_FIELDS setting. >> >> However, as the Mezzanine docs point out >> (http://mezzanine.jupo.org/docs/model-customization.html#field-injection-caveats), >> there are some "caveats" regarding migrations. >> >> Specifically, the migrations need to be placed in a local app even >> though they're applied to the Mezzanine models. >> >> What's the proper way to do this in Django 1.7? > > Perhaps someone with more experience with the new migrations system can > correct me, but I doubt there is a "proper way" - this is an unusual and > probably unsupported use case that I would guess was never envisioned in > the design. In general, changes to a model belong in the migrations for > that model's app. > > I'm not sure why the mezzanine docs don't mention using the > SOUTH_MIGRATION_MODULES setting (or Django 1.7 equivalent > MIGRATION_MODULES) to override the location of the mezzanine app's > migrations to a package in your project, where you can freely add custom > migrations without modifying mezzanine code. > > The downside of this approach is that if a new mezzanine version in the > future ships migrations for changes to their model, you'll have to copy > or regenerate those migrations yourself in your custom migrations > directory. That seems like a reasonable tradeoff in the situation where > you're effectively monkeypatching another app's models. > >> It's easy to do it with a monkeypatch. Here's an example: >> >> https://gist.github.com/jMyles/130050563ba96a7d7cc8 > > I don't see any monkeypatch there, just subclassing, which is not the > same thing. I'd say that looks like a very nice solution to the problem. > The level of "fiddling with internals" required seems roughly > proportional to the peculiarity of the use case; I doubt you'll find > anything better (other than perhaps avoiding the problem entirely by > using MIGRATION_MODULES). > > Carl > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/54595E83.7060706%40gmail.com. For more options, visit https://groups.google.com/d/optout.
