> I don't understand this use case. A ForeignKey impacts only one database table's schema; the table for the model on which the ForeignKey field is located. The schema of the model the ForeignKey points to doesn't need to change at all based on the presence or absence of some other ForeignKey pointing to it.
Example: Two apps: apps.coconuts and apps.swallows, each with a canonical model (Coconut and Swallow, respectively). The organization runs two version of the project: one with apps.swallows and one without. The one with apps.swallows needs a field on Coconut, "carried," which is a FK -=> Swallow. To me, the proper way to do this is to ship a migration in the swallows app which adds this field to apps.coconuts.models.Coconut. This is certainly a rare use case, but not a special case. On the other hand, I don't see the advantage of restricting the models which may be migrated to those in the app in which the migration appears, particularly now that migration dependencies are more straightforward. > I also wonder if there might be a way to do (2) without the monkeypatching. That is, could Mezzanine provide an importable Operation subclass for this purpose and document how to import and use it in a migration? On 11/04/2014 03:33 PM, Carl Meyer wrote: > Hi Justin, > > On 11/04/2014 04:17 PM, Justin Myles Holmes wrote: >> Hey Carl. Missed you so very much at DjangoCon. :-) > Thanks :-) > >>> 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 understand this use case. A ForeignKey impacts only one database > table's schema; the table for the model on which the ForeignKey field is > located. The schema of the model the ForeignKey points to doesn't need > to change at all based on the presence or absence of some other > ForeignKey pointing to it. > > It still seems to me that there isn't a good reason for Django to > support migrations that modify the schema of a model in some other app. > That's the migrations equivalent of monkeypatching, and I think it will > usually end in tears :-) > >>> 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. > Ah, I see. I didn't realize that you were looking for a generic solution > in Mezzanine, rather than a solution for your specific Mezzanine-using > project. > >> 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 > I think (2) is right out, and as I said above, I don't think this is a > use case Django should cover, which means (3) is out too. That leaves > (1)... although I also wonder if there might be a way to do (2) without > the monkeypatching. That is, could Mezzanine provide an importable > Operation subclass for this purpose and document how to import and use > it in a migration? > > 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/545963FF.5050701%40gmail.com. For more options, visit https://groups.google.com/d/optout.
