dj-stripe: Migration OperationalError after upgrading from 1.2.4 to 2.0.0 (cannot ALTER TABLE "djstripe_card")

Hello, I upgraded the library from version 1.2.4 to 2.0.0 and when I ran the migration I got the following error:

django.db.utils.OperationalError: cannot ALTER TABLE “djstripe_card” because it has pending trigger events

Here is the name of the migration: 0003_auto_20181117_2328_squashed_0004_auto_20190227_2114

And here is the stack trace:

Running migrations:
  Applying djstripe.0003_auto_20181117_2328_squashed_0004_auto_20190227_2114...Traceback (most recent call last):
  File "/home/alexandre/.local/share/virtualenvs/app-backend-Qo6u1eBR/lib/python3.6/site-packages/django/db/backends/utils.py", line 85, in _execute
    return self.cursor.execute(sql, params)
psycopg2.OperationalError: cannot ALTER TABLE "djstripe_card" because it has pending trigger events


The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "./manage.py", line 15, in <module>
    execute_from_command_line(sys.argv)
  File "/home/alexandre/.local/share/virtualenvs/app-backend-Qo6u1eBR/lib/python3.6/site-packages/django/core/management/__init__.py", line 381, in execute_from_command_line
    utility.execute()
  File "/home/alexandre/.local/share/virtualenvs/app-backend-Qo6u1eBR/lib/python3.6/site-packages/django/core/management/__init__.py", line 375, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/home/alexandre/.local/share/virtualenvs/app-backend-Qo6u1eBR/lib/python3.6/site-packages/django/core/management/base.py", line 316, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/home/alexandre/.local/share/virtualenvs/app-backend-Qo6u1eBR/lib/python3.6/site-packages/django/core/management/base.py", line 353, in execute
    output = self.handle(*args, **options)
  File "/home/alexandre/.local/share/virtualenvs/app-backend-Qo6u1eBR/lib/python3.6/site-packages/django/core/management/base.py", line 83, in wrapped
    res = handle_func(*args, **kwargs)
  File "/home/alexandre/.local/share/virtualenvs/app-backend-Qo6u1eBR/lib/python3.6/site-packages/django/core/management/commands/migrate.py", line 203, in handle
    fake_initial=fake_initial,
  File "/home/alexandre/.local/share/virtualenvs/app-backend-Qo6u1eBR/lib/python3.6/site-packages/django/db/migrations/executor.py", line 117, in migrate
    state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial)
  File "/home/alexandre/.local/share/virtualenvs/app-backend-Qo6u1eBR/lib/python3.6/site-packages/django/db/migrations/executor.py", line 147, in _migrate_all_forwards
    state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
  File "/home/alexandre/.local/share/virtualenvs/app-backend-Qo6u1eBR/lib/python3.6/site-packages/django/db/migrations/executor.py", line 244, in apply_migration
    state = migration.apply(state, schema_editor)
  File "/home/alexandre/.local/share/virtualenvs/app-backend-Qo6u1eBR/lib/python3.6/site-packages/django/db/migrations/migration.py", line 124, in apply
    operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
  File "/home/alexandre/.local/share/virtualenvs/app-backend-Qo6u1eBR/lib/python3.6/site-packages/django/db/migrations/operations/fields.py", line 216, in database_forwards
    schema_editor.alter_field(from_model, from_field, to_field)
  File "/home/alexandre/.local/share/virtualenvs/app-backend-Qo6u1eBR/lib/python3.6/site-packages/django/db/backends/base/schema.py", line 523, in alter_field
    old_db_params, new_db_params, strict)
  File "/home/alexandre/.local/share/virtualenvs/app-backend-Qo6u1eBR/lib/python3.6/site-packages/django/db/backends/postgresql/schema.py", line 122, in _alter_field
    new_db_params, strict,
  File "/home/alexandre/.local/share/virtualenvs/app-backend-Qo6u1eBR/lib/python3.6/site-packages/django/db/backends/base/schema.py", line 683, in _alter_field
    params,
  File "/home/alexandre/.local/share/virtualenvs/app-backend-Qo6u1eBR/lib/python3.6/site-packages/django/db/backends/base/schema.py", line 133, in execute
    cursor.execute(sql, params)
  File "/home/alexandre/.local/share/virtualenvs/app-backend-Qo6u1eBR/lib/python3.6/site-packages/django/db/backends/utils.py", line 100, in execute
    return super().execute(sql, params)
  File "/home/alexandre/.local/share/virtualenvs/app-backend-Qo6u1eBR/lib/python3.6/site-packages/django/db/backends/utils.py", line 68, in execute
    return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
  File "/home/alexandre/.local/share/virtualenvs/app-backend-Qo6u1eBR/lib/python3.6/site-packages/django/db/backends/utils.py", line 77, in _execute_with_wrappers
    return executor(sql, params, many, context)
  File "/home/alexandre/.local/share/virtualenvs/app-backend-Qo6u1eBR/lib/python3.6/site-packages/django/db/backends/utils.py", line 85, in _execute
    return self.cursor.execute(sql, params)
  File "/home/alexandre/.local/share/virtualenvs/app-backend-Qo6u1eBR/lib/python3.6/site-packages/django/db/utils.py", line 89, in __exit__
    raise dj_exc_value.with_traceback(traceback) from exc_value
  File "/home/alexandre/.local/share/virtualenvs/app-backend-Qo6u1eBR/lib/python3.6/site-packages/django/db/backends/utils.py", line 85, in _execute
    return self.cursor.execute(sql, params)
django.db.utils.OperationalError: cannot ALTER TABLE "djstripe_card" because it has pending trigger events

And this link might be useful: https://stackoverflow.com/questions/12838111/django-db-migrations-cannot-alter-table-because-it-has-pending-trigger-events

Any ideas?

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 1
Comments: 27 (25 by maintainers)

Commits related to this issue

Add manage command to workaround postgres migation issue To workaround migration problem on postgres - can't update and alter table in same transaction Resolves #850 — committed to prismaticd/dj-stripe by therefromhere 5 years ago
Add manage command to workaround postgres migation issue To workaround migration problem on postgres - can't update and alter table in same transaction Resolves #850 — committed to prismaticd/dj-stripe by therefromhere 5 years ago
Add manage command to workaround postgres migation issue To workaround migration problem on postgres - can't update and alter table in same transaction Resolves #850 — committed to prismaticd/dj-stripe by therefromhere 5 years ago
Add manage command to workaround postgres migation issue To workaround migration problem on postgres - can't update and alter table in same transaction Resolves #850 — committed to dj-stripe/dj-stripe by therefromhere 5 years ago
Add manage command to workaround postgres migation issue To workaround migration problem on postgres - can't update and alter table in same transaction Resolves #850 — committed to dj-stripe/dj-stripe by therefromhere 5 years ago

Most upvoted comments

@steverecio can you try running the manage command in https://github.com/dj-stripe/dj-stripe/pull/1171/files before running the 0003 migration - this is a branch from stable/2.0, so running that branch should be equivalent to running v2.0.5 + this command.

If that works you should then be able to migrate and then upgrade to newer versions.

BTW I would suggest upgrade one minor version at a time (1.3.latest, 2.0.latest etc) rather than trying to go straight from 1.3 to 2.3.

therefromhere on May 30, 2020

I’ve merged #863, I don’t think my #861 is needed - if anyone still has a problem they can still run the update commands by hand.

E.g. by importing the result of this:

./manage.py sqlmigrate djstripe 0003 | grep UPDATE > update.sql

therefromhere on Mar 17, 2019

The ./manage.py sqlmigrate does not give much information:

BEGIN;
--
-- MIGRATION NOW PERFORMS OPERATION THAT CANNOT BE WRITTEN AS SQL:
-- Raw Python operation
--
--
-- Alter field display_name on accountformation:
...

The documentation says

On databases that do support DDL transactions (SQLite and PostgreSQL), RunPython operations do not have any transactions automatically added besides the transactions created for each migration. Thus, on PostgreSQL, for example, you should avoid combining schema changes and RunPython operations in the same migration or you may hit errors like OperationalError: cannot ALTER TABLE “mytable” because it has pending trigger events.

https://docs.djangoproject.com/en/2.1/topics/migrations/#data-migrations

So the migration runs into one transaction, including the postgres prep Python script and then the schema updates. But regarding the warning I think this part of the documentation might be outdated

In my experience with Django/PostgreSQL 10+ it’s fine to do a RunPython before schema migrations (for example setting default values to null fields before making the column non nullable) or after (to compute some values for each object and populate a new field for example) in the same migration

When checking the comments on stack overflow thread I found this:

PostgreSQL probably changed its behaviour regarding such transactions, as I managed to run a migration with both data and schema changes on my dev machine (PostgreSQL 9.4) while it failed on the server (PostgreSQL 9.1). – Bertrand Bordage Jan 24 '15 at 17:49 Almost same for me. It worked flawlessly for 100+ migrations(including ~20 data migrations) until today, while adding unique together constraint along with data migration removing duplicates before it. PostgreSQL 10.0 –

So here I opened the PR which fixes the exception for recent postgres installations:

https://github.com/dj-stripe/dj-stripe/pull/863

And I think your command would still be useful for older versions of postgres who might still get the exception

alexandre-paroissien on Mar 11, 2019