-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
v4.0-beta1 migration "users.0008_flip_objectpermission_assignments..." fails #15698
Comments
This issue was reported under #15605 and has since been resolved in the |
I just noticed that you edited your post: Your stack trace does not match the issue title. Please update the title, and provide more detail about how to reproduce your issue. (Merely upgrading from v3.7.5 does not cause the error.) |
Sorry, in trying to reproduce the issue from #15605 cleanly I encountered an issue I caused myself. I changed the stack trace later after resetting my test environment. I've changed the title accordingly now. Cross-comparing the cleaned-up environment with a stock installation, it seems the former is missing users_objectpermissi_objectpermission_id_2f7cc117_fk_users_obj and users_objectpermissi_objectpermission_id_78a9c2e6_fk_users_obj. |
I haven't been able to determine how your database arrived in this state. The
When building a new database using the migrations present in NetBox v3.7, we can confirm that these constraints are created as expected. However, both you and @tobiasge (see #15726) appear to be missing them. While we could work around this in the v4.0 migration, the fact that the constraint appears to be missing is problematic on its own. |
I have done a few tests and I could manually add the missing FK constraints to get the migration to apply cleanly. I'm however also not sure about how the state of things ended up as it is, nor I can imagine how common an issue it is. Would it be worthwhile to have some form of pre-upgrade check that verifies the correctness of the database? |
I've also run into
while testing the migration from 3.7.5 to 4.0. I also appear to be missing the foreign key constraint:
I could add the constraint using
I assume there is another foreign key missing from
Adding this as well using |
Thank you for the confirmation. It seems we have at least three people who have encountered this issue, so I imagine it's fairly common for people with databases that originated prior to v2.9. While we can work around the immediate problem by making the renaming of the constraint conditional (ignoring the operation if the constraint does not exist), I still need to determine why it's missing. |
I can check on the archived pre-upgrade db dumps I have, that go back to 2.11.12, if it is of any help. I believe that was the original version our instance started as. |
I tried upgrading to feature branch from 3.7.5 (in the past we were on 2.8 and then migrated subsequently to the latest 2.x and then to every 3.x). I also got the following error:
|
This took a bit of digging but I believe I've uncovered the root issue. This can be replicated by following these steps:
I'm not sure why this happens. The operations = [
migrations.AlterField(
model_name='objectpermission',
name='id',
field=models.BigAutoField(primary_key=True, serialize=False),
),
migrations.AlterField(
model_name='token',
name='id',
field=models.BigAutoField(primary_key=True, serialize=False),
),
] My guess is we've hit some bug in Django 3.2, but I haven't attempted to locate one yet. This at least identifies the root cause of the migration issue, so I'm comfortable working around it as I mentioned above. Thank you everyone for your assistance in tracking this down! |
@a084ed22 @bogi788 @opericgithub @tobiasge I just submitted PR #15765 which I believe resolves this. Please try it out if you're able and let me know if you still encounter any issues running the v4.0 migrations. |
@jeremystretch I had the same problem. After I applied the PR, the migration went through without any further problems |
Deployment Type
Self-hosted
NetBox Version
v4.0-beta1
Python Version
3.11
Steps to Reproduce
I'm testing the upgrade between v3.7.5 and v4.0-beta1 on a separate system where I restored the database we're running and I'm encountering the following issue:
Somewhat relatedly, would it be possible and/or a good idea to have some form of consistency check before a major upgrade such as this, to ensure the correct presence and format of all the database objects with their expected names?
Expected Behavior
Update to the beta version should work without encountering issues due missing/differently named objects
Observed Behavior
Migrations fail due to unexpectedly missing database objects
The text was updated successfully, but these errors were encountered: