In case anybody was following this discussion:
I have written a blog post about my conclusions here:
https://kayemyles.com/blog/using-django-17s-migrations-framework-with-mezzanine/
...and opened an Issue in Mezzanine to address the situation here:
https://github.com/stephenmcd/mezzanine/issues/1
Carl:
Actually, the "subclass the operation" method fails for obvious reasons
here:
https://github.com/django/django/blob/df0523debcc2d0984f1bc11d323f04227d4b388b/django/apps/registry.py#L202
I'm increasingly thinking that using MIGRATION_MODULES and just
maintaining a local copy of Mezzanine's
Well, as I say, I don't particularly like this field injection notion,
and I'm happy to individually subclass where needed in my own projects.
I'm less surefooted about issuing a pull request to mezzanine to alter
their docs to suggest doing this, although the doc is currently
ambiguous enough to
Carl is right that this isn't a supported thing; Django models are designed
to be static, and not mutate based on settings.
Migrations are designed to only support one linear change history of
models; swappable models are just about supported but not perfect and leads
to issues. Adding in the a
Hi Justin,
On 11/04/2014 04:42 PM, Justin Myles Holmes wrote:
>> 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
> 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 point
> 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 point
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 locatio
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 fr
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
Hey friends!
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
11 matches
Mail list logo
