-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reusable apps can not be shipped with migrations #12
Comments
Thanks for the detailed report, I have come across similar issues. The short answer to the But the lazy reference issue is a bit harder to solve. I think it may have to do with django/django#6359 which was released with Django 1.10. Does the same thing happen with Django 1.9? Either way, there are some underlying assumptions in Django that make it difficult to have automatically generated migrations work as expected when you have multiple swappable models. So, maybe the best short term approach really is to not ship any migrations in a reusable app, though that does seem a bit funny. The long term approach is probably to submit a PR with some additional changes to Django - this and the other open tickets on this repo should be useful in identifying what those changes need to be. |
Thanks for the answer! Perhaps will be looking into that if I happen to have a bit of more time :) |
* use identify pattern for Site/ReportStatus/Parameter base models * don't check in migrations (see openwisp/django-swappable-models#12)
…migration files from core, and force user to run makemigrations upon installing waves core module. Just in cas someone wants to override defaults Service or Submission model
In your app you just create a basic modell just to have it in the db and create an initial migration without any swap and add this:
this way your model will exist by the time reusable app looks for swapped models and can create FK to it. |
Closed because it's not a bug but rather a configuration issue. |
Hello!
First of all, many thanks for this repo! I hope Django will ship this feature in its core in not such a distant future.
I think that migrations don't really work with this system (except for simple cases).
Consider 3 models with ForeignKey relationships, A -> B -> C (C depends on B which depends on A). If you swap model B for your own, you will run into a problem:
If you generated the migrations file in the reusable app, you basically end up with a circular import.
You can actually see the problem with the following example:
models.py
in the reusable app:models.py
in the other app:First attempt: we generate migrations for the reusable app first
In this first case, your other app is not in INSTALLED_APPS, and you only make migrations for your reusable app, so that it can create a proper database schema when installed.
So you run:
You get a nice migrations file:
You can, of course, modify it according to your documentation in order to avoid blindly reading configuration values from django.conf.settings which may not be defined:
And this works fine:
But now, lets say I want to use my other app that ships with its own version of the "B" model.
I add
other_app
toINSTALLED_APPS
and specifyREUSABLE_APP_B_MODEL = 'other_app.B'
. Now it doesn't work anymore…Well, Django is lying in a way. Because
other_app
IS
installed:I guess that Django doesn't see the
other_app
being installed because it reads thereusable_app.0001_initial
migration file, which doesn't depend on anything, so it loads it before loading theother_app
, and see references toother_app
that it cannot resolve.I tried to add fill the
dependencies
parameter inreusable_app.0001_initial
, I was hoping that it would trigger an import of theother_app
, but it didn't change anything:Second attempt: generate both migration files at the same time
So since generating migrations for the reusable app first doesn't work, there is a workaround. To clean things up, I just deleted the migrations file from the reusable app.
Now the only way to make the whole thing work is to type the following:
When I apply these migrations, they are executed in the following order:
I guess that Django splits migrations in order to resolve the circular dependencies issue.
In my real-life project, I have a much more complicated setup with 12 inter-dependent swappable models. I guess it can lead to even more complicated inter-depndencies…
The text was updated successfully, but these errors were encountered: