Migration discrepancy SQLite vs PostgreSQL

[eeintech]

On master, running inv migrate on instance using SQLite database outputs:

InvenTree Database Configuration
================================
ENGINE: django.db.backends.sqlite3
NAME: ../inventree_default_db.sqlite3
HOST: ''
Operations to perform:
  Apply all migrations: admin, auth, authtoken, build, common, company, contenttypes, django_q, error_report, exchange, label, order, part, report, sessions, stock, users
Running migrations:
  No migrations to apply

Which is correct I believe. Now running the same command on a PostgreSQL database:

Running InvenTree database migrations...
========================================
InvenTree Database Configuration
================================
ENGINE: django.db.backends.postgresql
NAME: inventree-elec
HOST: 127.0.0.1
Migrations for 'company':
  company/migrations/0039_auto_20210622_1343.py
    - Alter field price on supplierpricebreak
    - Alter field price_currency on supplierpricebreak
Migrations for 'order':
  order/migrations/0047_auto_20210622_1343.py
    - Alter field purchase_price on purchaseorderlineitem
    - Alter field purchase_price_currency on purchaseorderlineitem
    - Alter field sale_price on salesorderlineitem
    - Alter field sale_price_currency on salesorderlineitem
Migrations for 'part':
  part/migrations/0069_auto_20210622_1343.py
    - Alter field price on partinternalpricebreak
    - Alter field price_currency on partinternalpricebreak
    - Alter field price on partsellpricebreak
    - Alter field price_currency on partsellpricebreak
Migrations for 'stock':
  stock/migrations/0065_auto_20210622_1343.py
    - Alter field purchase_price on stockitem
    - Alter field purchase_price_currency on stockitem
InvenTree Database Configuration
================================
ENGINE: django.db.backends.postgresql
NAME: inventree-elec
HOST: 127.0.0.1
Operations to perform:
  Apply all migrations: admin, auth, authtoken, build, common, company, contenttypes, django_q, error_report, exchange, label, order, part, report, sessions, stock, users
Running migrations:
  Applying company.0039_auto_20210622_1343... OK
  Applying order.0047_auto_20210622_1343... OK
  Applying part.0069_auto_20210622_1343... OK
  Applying stock.0065_auto_20210622_1343... OK
InvenTree Database Configuration
================================
ENGINE: django.db.backends.postgresql
NAME: inventree-elec
HOST: 127.0.0.1
Operations to perform:
  Synchronize unmigrated apps: InvenTree, corsheaders, crispy_forms, django_cleanup, django_filters, djmoney, formtools, import_export, markdownify, markdownx, messages, mptt, rest_framework, staticfiles
  Apply all migrations: admin, auth, authtoken, build, common, company, contenttypes, django_q, error_report, exchange, label, order, part, report, sessions, stock, users
Synchronizing apps without migrations:
  Creating tables...
    Running deferred SQL...
Running migrations:
  No migrations to apply.
InvenTree Database Configuration
================================
ENGINE: django.db.backends.postgresql
NAME: inventree-elec
HOST: 127.0.0.1
System check identified no issues (0 silenced).
========================================
InvenTree database migrations completed!

It creates 4 new migration files, running git status:

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    InvenTree/company/migrations/0039_auto_20210622_1343.py
    InvenTree/order/migrations/0047_auto_20210622_1343.py
    InvenTree/part/migrations/0069_auto_20210622_1343.py
    InvenTree/stock/migrations/0065_auto_20210622_1343.py

Not sure where the discrepancy comes from, and not sure if it is a real issue but I am quite confused why would the Django ORM behave differently on different types of databases. Also not sure if those migration files should be plugged into master.

[matmair]

@eeintech this is a upstream problem of our money dependency see #1674

[matmair]

Duplicate of #1674

[eeintech]

Oh right, I have a very short memory... :weary:

[matmair]

@eeintech me too, I just remember because I tried to fix it and concluded that it was a upstream problem.

[SchrodingersGat]

We do need to address #1674 reasonably soon to prevent these erroneous migrations from upsetting master.

[matmair]

@SchrodingersGat as far as i can understand the problem only upstream can address this? Or should we try inheriting the model-field to change the migration procedure? Could try that on the weekend.

[SchrodingersGat]

It might be worth implementing our own InvenTreeMoneyField as you say.

I would like to see the currency options (default, allowed currency codes) moved out of the config file and into the InvenTree run-time settings. It should not require a sysadmin to change these settings, but the current restrictions of MoneyField force our hand.