You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since there is no "previous" version/schema for the first migration that is being run right after pgroll init, segv happens for column related changes such as adding unique constaint or a column; similar to #623
Having no previous version/schema might cause segv during Rollback, because it first tries to fetch the schema before the migration, in order to replay that migration on that schema. A similar issue that is happening when a sql command is run between migrations is fixed in #631 by taking inferred migrations into account. However, if the sql command is not added into migrations table, presumably because it is executed before pgroll init, pgroll wouldn't be able to find it.
To reproduce, first create a table:
createtableproducts (id serialprimary key, name varchar(255) unique, price decimal(10,2));
Since there is no "previous" version/schema for the first migration that is being run right after
pgroll init
, segv happens for column related changes such as adding unique constaint or a column; similar to #623Having no previous version/schema might cause segv during
Rollback
, because it first tries to fetch the schema before the migration, in order to replay that migration on that schema. A similar issue that is happening when a sql command is run between migrations is fixed in #631 by takinginferred
migrations into account. However, if the sql command is not added intomigrations
table, presumably because it is executed beforepgroll init
,pgroll
wouldn't be able to find it.To reproduce, first create a table:
Then:
We should consider doing a
read_schema
during theinit
phase and save it to somewhere, probably into migrations table.The text was updated successfully, but these errors were encountered: