Skip to content
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

Dropping columns results in duplicate inferred migrations #304

Closed
andrew-farries opened this issue Mar 5, 2024 · 0 comments · Fixed by #305
Closed

Dropping columns results in duplicate inferred migrations #304

andrew-farries opened this issue Mar 5, 2024 · 0 comments · Fixed by #305
Assignees
Labels
bug Something isn't working

Comments

@andrew-farries
Copy link
Collaborator

Dropping columns outside of a pgroll migration results in a duplicate inferred migration in the pgroll.migrations table.

To reproduce:

In a fresh Postgres instance:

  • initialize pgroll:
pgroll init
  • create a table
create table foo(a serial primary key, b text)
  • drop a column:
alter table foo drop column b
  • view the pgroll.migrations table:
select * from pgroll.migrations order by created_at desc

Actual behaviour:

The pgroll.migrations table contains two entries for the inferred column drop:

+--------+--------------------+-------------------------------------------------------------------------------------------------------------------+----------------------------+----------------------------+--------------------+------+-------------------------------------------------------------------------------------->
| schema | name               | migration                                                                                                         | created_at                 | updated_at                 | parent             | done | resulting_schema                                                                     >
|--------+--------------------+-------------------------------------------------------------------------------------------------------------------+----------------------------+----------------------------+--------------------+------+-------------------------------------------------------------------------------------->
| public | sql_0adcbadf878e88 | {"name": "sql_0adcbadf878e88", "operations": [{"sql": {"up": "alter table foo drop column b"}}]}                  | 2024-03-05 10:49:56.732626 | 2024-03-05 10:49:56.732626 | sql_a75d0c69f0cfe2 | True | {"name": "public", "tables": {"foo": {"oid": "16415", "name": "foo", "columns": {"a":>
| public | sql_ba9fefdb42a66c | {"name": "sql_ba9fefdb42a66c", "operations": [{"sql": {"up": "alter table foo drop column b"}}]}                  | 2024-03-05 10:49:56.732626 | 2024-03-05 10:49:56.732626 | sql_0adcbadf878e88 | True | {"name": "public", "tables": {"foo": {"oid": "16415", "name": "foo", "columns": {"a":>
| public | sql_a75d0c69f0cfe2 | {"name": "sql_a75d0c69f0cfe2", "operations": [{"sql": {"up": "create table foo(a serial primary key, b text)"}}]} | 2024-03-05 10:49:48.964148 | 2024-03-05 10:49:48.964148 | <null>             | True | {"name": "public", "tables": {"foo": {"oid": "16415", "name": "foo", "columns": {"a":>
+--------+--------------------+-------------------------------------------------------------------------------------------------------------------+

Expected behaviour:

There is exacly one inferred migration corresponding to the column drop.

@andrew-farries andrew-farries added the bug Something isn't working label Mar 5, 2024
@andrew-farries andrew-farries self-assigned this Mar 5, 2024
andrew-farries added a commit that referenced this issue Mar 6, 2024
…migration (#305)

Ensure that only one `inferred` migration is created in the
`pgroll.migrations` table when a column is dropped outside of a
migration.

From the Postgres
[docs](https://www.postgresql.org/docs/current/event-trigger-definition.html):
> The sql_drop event occurs just before the ddl_command_end event
trigger for any operation that drops database objects

This means that when the `raw_migration` function is run in response to
`sql_drop` and `ddl_command_end`, duplicate entries will be created in
`pgroll.migrations`; once as the function is run for `sql_drop` and
again when it's run for `ddl_command_end`.

Change the definition of the `pg_roll_handle_drop` event trigger to only
run on those kinds of drops that won't result in duplicates when the
`pg_roll_handle_ddl` trigger runs for the same change. `DROP TABLE` and
`DROP VIEW` won't result in duplicate migrations because their schema
can't be inferred by the `ddl_command_event` trigger because the object
has already been dropped when the trigger runs.

Update the inferred migration tests with two new testcases covering
dropping tables and columns.

Fixes #304
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant