-
-
Notifications
You must be signed in to change notification settings - Fork 824
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
Failed migration from 0.16.9 -> 0.17.1 multiple assignments to same column "status_custom_key"
#8796
Comments
@lifeisafractal thanks for the report. Are you using any custom status values for your sales orders? If you have a dataset that you can export (via |
Hi @SchrodingersGat, I wasn't aware you could do custom sales order status values, so I don't think I am. It looks like all the status fields for the salesorder model instances match up against a value in the // cat data.json|jq '.[] | select( .model == "order.salesorder" ) | .fields.status '|jq -cs 'sort_by(.)|unique'
[10,15,20,30,40] I'm only handy enough to be dangerous with these things, but it looks like the failing migration is getting triggered on these sales orders that are completed, but don't have a shipping date.
|
As a work around to get on 0.17.1, I manually added ship dates to those two sales orders in the admin interface. After that, I could successfully migrate and update to 0.17.1. I'm good now since I won't need to do this again, but I'm happy to help out if you want to root cause this further. I still have the json data dump if we want to poke at it, and I can also deploy a sandbox instance from my backups with the older data if we want to experiment with anything ( If this feels like an edge case you don't want to dig further on, feel free to close out this issue. Thanks @SchrodingersGat and the whole Inventree team for all your great work! |
The issue with this data migration seems to be related to an issue I came across during the original migration: @matmair this appears to be something to do with the way that the custom status fields are attached to the model. During a "migration" run, the field seems to be attached multiple times... |
Can reproduce; not sure why - looking into it |
@matmair have you made any progress on this? I am holding off on |
Not really, I am playing around with the migrations but I do not really know where this is comming from |
I have a solution, will submit in the next few hours |
…column "status_custom_key"` Fixes inventree#8796
it seems to work in matmair#281; maybe I need to change the migration order |
@matmair intersting.. would be good to get a patch in for 0.17.2 if changing the order works |
@matmair did you come to a conclusion here? |
Please verify that this bug has NOT been raised before.
Describe the bug*
I'm trying to update my docker instance of inventree from 0.16.9 to 0.17.1. When running
docker compose run --rm inventree-server invoke update
I get the errordjango.db.utils.ProgrammingError: multiple assignments to same column "status_custom_key"
(see full logs below). I'm not really sure how to address this and it's blocking me from upgrading to 0.17.x.I tried wiping the database info and leaving all other settings, files, and configs in my setup the same, and I am able to deploy a fresh setup. This seems to point to some kind of issue in my database messing up the migration and not something else spurious about my setup.
Steps to Reproduce
Unfortunately this seems to be unique to my database and I can't share that publicly. I'm happy to share data with developers privately to try and debug this.
Expected behaviour
Expect to be able to migrate and start the server with all existing data.
Deployment Method
Version Information
Below is the version info from my working instance on 0.16.9
Version Information:
InvenTree-Version: 0.16.9
Django Version: 4.2.15
Commit Hash: e0756a7
Commit Date: 2024-11-30
Database: postgresql
Debug-Mode: False
Deployed using Docker: True
Platform: Linux-6.6.51+rpt-rpi-2712-aarch64-with
Installer: DOC
Active plugins: [{'name': 'InvenTreeBarcode', 'slug': 'inventreebarcode', 'version': '2.1.0'}, {'name': 'InvenTreeCoreNotificationsPlugin', 'slug': 'inventreecorenotificationsplugin', 'version': '1.0.0'}, {'name': 'InvenTreeCurrencyExchange', 'slug': 'inventreecurrencyexchange', 'version': '1.0.0'}, {'name': 'InvenTreeLabel', 'slug': 'inventreelabel', 'version': '1.1.0'}, {'name': 'InvenTreeLabelMachine', 'slug': 'inventreelabelmachine', 'version': '1.0.0'}, {'name': 'InvenTreeLabelSheet', 'slug': 'inventreelabelsheet', 'version': '1.0.0'}, {'name': 'DigiKeyPlugin', 'slug': 'digikeyplugin', 'version': '1.0.0'}, {'name': 'LCSCPlugin', 'slug': 'lcscplugin', 'version': '1.0.0'}, {'name': 'MouserPlugin', 'slug': 'mouserplugin', 'version': '1.0.0'}, {'name': 'TMEPlugin', 'slug': 'tmeplugin', 'version': '1.0.0'}, {'name': 'IPNAutoGenerator', 'slug': 'ipnautogenerator', 'version': None}, {'name': 'KiCadLibraryPlugin', 'slug': 'kicad-library-plugin', 'version': '1.4.3'}]
Please verify if you can reproduce this bug on the demo site.
Relevant log output
The text was updated successfully, but these errors were encountered: