Bug #23134
migrations "squash" ne passent pas en postgresql
100%
Description
Avec un local_settings.py qui tape en postgresql :
(venv) thomas@zepo:~/.../src/fargo [master ↑·1|…73]$ ./manage.py migrate Operations to perform: Synchronize unmigrated apps: staticfiles, gadjo, messages, django_tables2, rest_framework Apply all migrations: oauth2, sessions, admin, auth, contenttypes, fargo, thumbnail Synchronizing apps without migrations: Creating tables... Running deferred SQL... Installing custom SQL... Running migrations: Rendering model states... DONE Applying contenttypes.0001_initial... OK Applying auth.0001_initial... OK Applying admin.0001_initial... OK Applying contenttypes.0002_remove_content_type_name... OK Applying auth.0002_alter_permission_name_max_length... OK Applying auth.0003_alter_user_email_max_length... OK Applying auth.0004_alter_user_username_opts... OK Applying auth.0005_alter_user_last_login_null... OK Applying auth.0006_require_contenttypes_0002... OK Applying fargo.0001_squashed_0017_auto_20180331_1532...Traceback (most recent call last): File "./manage.py", line 10, in <module> execute_from_command_line(sys.argv) File "/home/thomas/dev/publik/venv/lib/python2.7/site-packages/django/core/management/__init__.py", line 354, in execute_from_command_line utility.execute() File "/home/thomas/dev/publik/venv/lib/python2.7/site-packages/django/core/management/__init__.py", line 346, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/home/thomas/dev/publik/venv/lib/python2.7/site-packages/django/core/management/base.py", line 394, in run_from_argv self.execute(*args, **cmd_options) File "/home/thomas/dev/publik/venv/lib/python2.7/site-packages/django/core/management/base.py", line 445, in execute output = self.handle(*args, **options) File "/home/thomas/dev/publik/venv/lib/python2.7/site-packages/django/core/management/commands/migrate.py", line 222, in handle executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial) File "/home/thomas/dev/publik/venv/lib/python2.7/site-packages/django/db/migrations/executor.py", line 110, in migrate self.apply_migration(states[migration], migration, fake=fake, fake_initial=fake_initial) File "/home/thomas/dev/publik/venv/lib/python2.7/site-packages/django/db/migrations/executor.py", line 148, in apply_migration state = migration.apply(state, schema_editor) File "/home/thomas/dev/publik/venv/lib/python2.7/site-packages/django/db/backends/base/schema.py", line 91, in __exit__ self.execute(sql) File "/home/thomas/dev/publik/venv/lib/python2.7/site-packages/django/db/backends/base/schema.py", line 111, in execute cursor.execute(sql, params) File "/home/thomas/dev/publik/venv/lib/python2.7/site-packages/django/db/backends/utils.py", line 79, in execute return super(CursorDebugWrapper, self).execute(sql, params) File "/home/thomas/dev/publik/venv/lib/python2.7/site-packages/django/db/backends/utils.py", line 64, in execute return self.cursor.execute(sql, params) File "/home/thomas/dev/publik/venv/lib/python2.7/site-packages/django/db/utils.py", line 98, in __exit__ six.reraise(dj_exc_type, dj_exc_value, traceback) File "/home/thomas/dev/publik/venv/lib/python2.7/site-packages/django/db/backends/utils.py", line 64, in execute return self.cursor.execute(sql, params) django.db.utils.ProgrammingError: ERREUR: la colonne « user_id » référencée dans la contrainte de clé étrangère n'existe pas
Si je retire les ./fargo/oauth2/migrations/0001_squashed_0005_auto_20180331_1532.py ./fargo/fargo/migrations/0001_squashed_0017_auto_20180331_1532.py tout passe.
Fichiers
Révisions associées
migrations: recreate squashed migrations from scratch (fixes #23134)
tests: fix no determinism in tests when using postgresql (#23134)
Historique
Mis à jour par Thomas Noël il y a environ 6 ans
- Fichier 0001-remove-squash-migrations-23134.patch 0001-remove-squash-migrations-23134.patch ajouté
- Statut changé de Nouveau à En cours
- Patch proposed changé de Non à Oui
+ voir comment inclure un simple test d'un migrate avec postgresql, pour ne plus avoir ce genre de pépin à l'avenir.
Mis à jour par Benjamin Dauvergne il y a environ 6 ans
Chez moi ça marche, en django 1.8 et 1.11.
(fargo) bdauvergne@revestel:~/wd/eo/fargo$ ./manage.py migrate Operations to perform: Apply all migrations: admin, auth, contenttypes, fargo, oauth2, sessions, thumbnail Running migrations: Applying contenttypes.0001_initial... OK Applying auth.0001_initial... OK Applying admin.0001_initial... OK Applying admin.0002_logentry_remove_auto_add... OK Applying contenttypes.0002_remove_content_type_name... OK Applying auth.0002_alter_permission_name_max_length... OK Applying auth.0003_alter_user_email_max_length... OK Applying auth.0004_alter_user_username_opts... OK Applying auth.0005_alter_user_last_login_null... OK Applying auth.0006_require_contenttypes_0002... OK Applying auth.0007_alter_validators_add_error_messages... OK Applying auth.0008_alter_user_username_max_length... OK Applying fargo.0001_squashed_0017_auto_20180331_1532... OK Applying oauth2.0001_squashed_0005_auto_20180331_1532... OK Applying sessions.0001_initial... OK Applying thumbnail.0001_initial... OK (fargo) bdauvergne@revestel:~/wd/eo/fargo$ pip freeze | grep -i django You are using pip version 9.0.2, however version 9.0.3 is available. You should consider upgrading via the 'pip install --upgrade pip' command. Django==1.11.11 django-debug-toolbar==1.9.1 django-filter==1.1.0 django-jsonfield==1.0.1 django-tables2==1.21.1 djangorestframework==3.3.3 (fargo) bdauvergne@revestel:~/wd/eo/fargo$ git checkout django\<1.9 error: pathspec 'django<1.9' did not match any file(s) known to git. (fargo) bdauvergne@revestel:~/wd/eo/fargo$ pip install django\<1.9 Collecting django<1.9 Using cached Django-1.8.19-py2.py3-none-any.whl Installing collected packages: django Found existing installation: Django 1.11.11 Uninstalling Django-1.11.11: Successfully uninstalled Django-1.11.11 Successfully installed django-1.8.19 liYou are using pip version 9.0.2, however version 9.0.3 is available. You should consider upgrading via the 'pip install --upgrade pip' command. (fargo) bdauvergne@revestel:~/wd/eo/fargo$ rm fargo.sqlite3 (fargo) bdauvergne@revestel:~/wd/eo/fargo$ pip install 'django-tables2<1.1' Collecting django-tables2<1.1 Downloading https://files.pythonhosted.org/packages/16/3e/3ffef55de28925266f9d8aa88d8e9d2813709254e04a4a805f87ddfa6a73/django-tables2-1.0.7.tar.gz (966kB) 100% |████████████████████████████████| 972kB 359kB/s Requirement already satisfied: Django>=1.7 in /home/bdauvergne/.virtualenvs/fargo/lib/python2.7/site-packages (from django-tables2<1.1) Requirement already satisfied: six in /home/bdauvergne/.virtualenvs/fargo/lib/python2.7/site-packages (from django-tables2<1.1) Building wheels for collected packages: django-tables2 Running setup.py bdist_wheel for django-tables2 ... done Stored in directory: /home/bdauvergne/.cache/pip/wheels/76/e7/ab/f401178389425ee114dd28f214dbb240ae9c041fc46c57fbe2 Successfully built django-tables2 Installing collected packages: django-tables2 Found existing installation: django-tables2 1.21.1 Uninstalling django-tables2-1.21.1: Successfully uninstalled django-tables2-1.21.1 Successfully installed django-tables2-1.0.7 You are using pip version 9.0.2, however version 9.0.3 is available. You should consider upgrading via the 'pip install --upgrade pip' command. (fargo) bdauvergne@revestel:~/wd/eo/fargo$ ./manage.py migrate Operations to perform: Synchronize unmigrated apps: messages, staticfiles, debug_toolbar, gadjo, django_tables2, rest_framework Apply all migrations: oauth2, sessions, admin, auth, contenttypes, fargo, thumbnail Synchronizing apps without migrations: Creating tables... Running deferred SQL... Installing custom SQL... Running migrations: Rendering model states... DONE Applying contenttypes.0001_initial... OK Applying auth.0001_initial... OK Applying admin.0001_initial... OK Applying contenttypes.0002_remove_content_type_name... OK Applying auth.0002_alter_permission_name_max_length... OK Applying auth.0003_alter_user_email_max_length... OK Applying auth.0004_alter_user_username_opts... OK Applying auth.0005_alter_user_last_login_null... OK Applying auth.0006_require_contenttypes_0002... OK Applying fargo.0001_squashed_0017_auto_20180331_1532... OK Applying oauth2.0001_squashed_0005_auto_20180331_1532... OK Applying sessions.0001_initial... OK Applying thumbnail.0001_initial... OK
Mis à jour par Thomas Noël il y a environ 6 ans
Benjamin Dauvergne a écrit :
Chez moi ça marche, en django 1.8 et 1.11.
C'est PostgreSQL qui fait partir l'affaire en live chez moi.
Mis à jour par Benjamin Dauvergne il y a environ 6 ans
- Fichier 0001-tox.ini-run-tests-with-postgresql-23134.patch 0001-tox.ini-run-tests-with-postgresql-23134.patch ajouté
- Fichier 0002-migrations-recreate-squashed-migrations-from-scratch.patch 0002-migrations-recreate-squashed-migrations-from-scratch.patch ajouté
Je n'ai pas compris le souci avec pg, j'ai préféré reconstruire la migration squashée depuis une migration initiale toute neuve.
Mis à jour par Thomas Noël il y a environ 6 ans
migrate tranquille, mais pour le coup, j'ai des erreurs sur « tox -e coverage-dj18-pg » (qui ne sont pas toujours les mêmes...)
Genre :
def test_push_document_slashed_name(app, admin_user, john_doe): login(app) url = reverse('fargo-api-push-document') data = { 'user_email': john_doe.email, 'origin': 'wcs', 'file_b64_content': base64.b64encode('whatever'), 'file_name': 'monfichier 18/06/2017.pdf', } response = app.post_json(url, params=data, status=200) assert response.json['result'] == 1 assert models.Document.objects.count() == 1 doc = models.UserDocument.objects.first() assert doc.filename == 'monfichier 18/06/2017.pdf' > assert doc.get_download_url() == '/1/download/monfichier%252018%252F06%252F2017.pdf' E AssertionError: assert '/7/download/...%252F2017.pdf' == '/1/download/m...%252F2017.pdf' E Skipping 38 identical trailing characters in diff, use -v to show E - /7/download E ? ^ E + /1/download E ? ^
Il doit manquer des mises à zéro...?
Mis à jour par Benjamin Dauvergne il y a environ 6 ans
- Fichier 0001-tests-fix-no-determinism-in-tests-when-using-postgre.patch 0001-tests-fix-no-determinism-in-tests-when-using-postgre.patch ajouté
Et un dernier patch pour corriger les bons petits tests des pères Kouka et Jaillet avec postgresql.
Mis à jour par Benjamin Dauvergne il y a environ 6 ans
Thomas Noël a écrit :
migrate tranquille, mais pour le coup, j'ai des erreurs sur « tox -e coverage-dj18-pg » (qui ne sont pas toujours les mêmes...)
Genre :
[...]
Il doit manquer des mises à zéro...?
En postgresql les séquences ne sont jamais remises à zéro, on ne peut pas prévoir les pk.
Mis à jour par Benjamin Dauvergne il y a environ 6 ans
- Statut changé de En cours à Résolu (à déployer)
- % réalisé changé de 0 à 100
Appliqué par commit d7360895c75ea02dcf1a74ef8a0d0f9bb3cb9ddd.
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Statut changé de Résolu (à déployer) à Solution déployée
tox.ini: run tests with postgresql (#23134)