Re: A migration in one app that adds a field to another

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJUVbA4AAoJEC0ft5FqUuEhQ3QP/1osgaIFpivjzbqd8nuF1Abh
n4MYu/umZq4QcISYUGP7s33n4MnHtzeA1j3OSrsmZ/d9YoBETWnTaU0T9lrT9EuO
IAnXE4u+xFaqWjJSZrSCemFled1JNCCO91p3BVj0kOFve0JH2OHEu0ZukQxCoxIz
o+d1QsWb4sYbWY8YXMuHJ00r5QtVkKtOfm4iMfpWJP3S9Td8kpJ8tKSq0oPUIiL7
CMOGOaqZywODLDue7GC8R9J8sfQX2i2ohpH2zfBY7srumvvppAix2GFgfydqcbSJ
tOOirQjYnzSyMiQCOKjWFfw6dQrH85qCOaZvNCoB2YOic7dRNdm5lwvBUk1JroTg
iVLfhZiGoAzyFYV13X15FPdEa6LvXjW/dur/9p9MD27i/L//E7cyifdjaZ+kYkHO
YoKsThWCMPK3vuSAijlwE/d35hqSIBbkcUy3kCH1+zgMfdvr53NqktcX8yvssVq7
9iK1bv1As0vux8ViL6A1APu2ylMXf15DJdhHDSTamzbUaK7sElawtNpVFz/C12/z
ZIEjGvomf25eAaDYmqABtctGfjZlQCmFPrAGgxGfFhPsxUZIywG4fYE5R+IlbIPO
AHC2SBi3VKwNK9y0nUUDwej+pOh/Vsg+knQS6x/Dfv56Cc4AtAH5QS5cg4IKsaQk
3KTHz7l0teOvl3Koxr6c
=sSsX
-----END PGP SIGNATURE-----
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