Thanks Ryne, for the explanation of MIGRATION_MODULES setting.
I've finally dealt with extension migrations and avoided burden of other
apps migrations shipping at the same time.
For a reference, brief info which seems to work with Django 1.8+
1. assign extra model fields in package's
Hi Ryne,
that would be a great help!
Thanks
On Wed, Nov 16, 2016 11:21 AM, Ryne Everett ryneever...@gmail.com
wrote:
I'm aware of this option, but it is a dictionary with application name > as a
key, right ? How can I tell Django to look for /cartridge.shop/ > migrations
both at
I'm aware of this option, but it is a dictionary with application name
as a key, right ? How can I tell Django to look for /cartridge.shop/
migrations both at original path and my extension package ?
In this case the application name is just /shop/. After setting up
MIGRATION_MODULES, your
> Without knowing exactly which models you're modifying, I would recommend
> to avoid field injection in reusable apps. If you're injecting stuff on
> Page, it might be better to create a custom Page type and distribute
> that with your package. See:
>
I extend models which are not designed
Without knowing exactly which models you're modifying, I would recommend
to avoid field injection in reusable apps. If you're injecting stuff on
Page, it might be better to create a custom Page type and distribute
that with your package. See:
Fixed *class_prepared* signal call (due to weak reference to handler) but
issue with migrations remains.
--
You received this message because you are subscribed to the Google Groups
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
