Migrating from 2.0.4 to 2.1 with a forked order app

[Maik Hoepfel]

Hi everyone,

lovely work on the 2.1 release! I especially like the communications refactor; it's something I've wanted for a long time. Also really happy about you offering LTS releases.

I am maintaining an Oscar shop that currently sits at 2.0.4, and I'd like to make the upgrade to 2.1. Among other apps, the order app is forked, including it's own migrations. I'm having trouble getting migrations created.

I followed the upgrading docs. First, I checked if there were any data migrations between 2.0.4 and 2.1, and luckily there aren't. So I added the new communications app to INSTALLED_APPS, and tried ./manage.py makemigrations.

That fails, because the communication.0002 migration references an order migration that doesn't exist in my project. So, am I right in assuming that I need to fork the app?

So, I forked the communications app. There are three approaches I tried:

Vanilla fork: The fork command copies the migrations. That (expectedly) fails because the referenced order migration still doesn't exist.

Fresh migrations: Okay, sure. Let's just delete the communication migrations and create new ones afresh. Unfortunately, when trying to makemigrations, it fails with:

ValueError: The field order.CommunicationEvent.event_type was declared with a lazy reference to 'customer.communicationeventtype',
but app 'customer' doesn't provide model 'communicationeventtype'.

I think the issue is that existing order migrations still point to "customer.CommunicationEventType". And Django can't detect models being moved between apps.

Set migration dependencies to new heads: So, I start down the rabbit hole of manually editing migrations. I copy the communications migrations again, but replace references to the order and catalogue migrations within them to the latest respective migrations in my forks. Unfortunately, that fails with the same error as above.

At this point, I'm stuck and am wondering if somebody has an idea on how to proceed? I can't be the only one with a forked order app that is doing the upgrade?

If it helps, I don't actually use the communication models, so I'm fine with deleting the contents of the tables - I don't need to get a proper move/rename working.

Thanks a bunch,

Maik

[solari...@gmail.com]

Hi Maik,

lovely work on the 2.1 release! I especially like the communications refactor; it's something I've wanted for a long time. Also really happy about you offering LTS releases.

Oscar 3.0 is out (in beta) - you might consider upgrading to that!

 

That fails, because the communication.0002 migration references an order migration that doesn't exist in my project. So, am I right in assuming that I need to fork the app?

No, you don't need to fork the app. This is a common problem with the interdependencies in oscar apps, and one which is easily solved. You just need to create an empty migration (manage.py makemigrations --empty order) and rename it to the name that is referenced by the Oscar app that depends on it - e.g., 0008_auto_20190301_1035 . This will allow the migrations to run, without the need to fork the communications app.

Also as much as possible you should try to mirror Oscar's migrations for your forked apps - i.e., copy the migration files across if possible, and use the same names - this will reduce the chance that you run into this issue.

Hope this helps,

Samir

[Ben Stähli]

Hi all

interesting point...is this procedure (mimicking migrations) described
somewhere? I have heavily migrated around in my forked apps...may there
be some bad surprises when updating?

thx
ben

> --
> https://github.com/django-oscar/django-oscar
> http://django-oscar.readthedocs.org/en/latest/
> ---
> You received this message because you are subscribed to the Google
> Groups "django-oscar" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-oscar...@googlegroups.com
> <mailto:django-oscar...@googlegroups.com>.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/django-oscar/bc900252-c623-48f3-80ea-be591b00eec9n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-oscar/bc900252-c623-48f3-80ea-be591b00eec9n%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
Ben Stähli
bn...@bnzk.ch
+41 22 575 25 77
bnzk.ch
--

[solari...@gmail.com]

Is this procedure (mimicking migrations) described somewhere?

It's probably not in the documentation, no, but would definitely benefit from being there as I'm sure others have encountered the same issue.

 

I have heavily migrated around in my forked apps...may there be some bad surprises when updating?

Making your own migrations will work generally - just increases the risk of dependency issues like the one raised here. You also need to review Oscar's migrations carefully as some of them (especially in 2.1 and 3.0) are data migrations which `makemigrations` is not going to know about. We do try to document these in the release notes.

Cheers,

Samir

 

[Ben Stähli]

good to know - thank you!

> --
> https://github.com/django-oscar/django-oscar
> http://django-oscar.readthedocs.org/en/latest/
> ---
> You received this message because you are subscribed to the Google
> Groups "django-oscar" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-oscar...@googlegroups.com
> <mailto:django-oscar...@googlegroups.com>.
> To view this discussion on the web, visit

> https://groups.google.com/d/msgid/django-oscar/183dad0f-cf2d-49da-b4e5-4eaf5b44ff21n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-oscar/183dad0f-cf2d-49da-b4e5-4eaf5b44ff21n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Maik Hoepfel]

Samir,

thank you for the prompt reply.

Re 3.0: Congrats on the new release. But the current project has been in maintenance mode for years, and I am happy to stick to LTS releases.

What you describe makes sense! I created the two empty migrations (catalogue, order), and needed to manually carry across the AlterField statement from order/0008_auto_20190301_1035 into the migration with the same filename, and had to add an dependency on the initial communication migration. I let `makemigrations` take care of the rest, and could migrate across. Thanks a bunch! For anyone interested, the final migration is here.

Cheers,

Maik

[Maik Höpfel]

PS. I've tried to distill the takeaways from this thread in a docs PR https://github.com/django-oscar/django-oscar/pull/3626/

To unsubscribe from this group and stop receiving emails from it, send an email to django-oscar...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/django-oscar/a07d7c7d-52e6-4077-87ae-2121d33df953n%40googlegroups.com.