multiSchema + migrate: decide whether the `_prisma_migrations` table living in the search path's first schema is correct #16565

tomhoule · 2022-12-01T07:13:39Z

Pros:

Mostly works
Avoids potential footguns with more configuration knobs (accidental changes)

Cons:

The Prisma schema defines the schemas the application owns and manages. The migrations table is potentially in none of these.

Before this commit, the migration engine `reset` command resets the schema in the search path, on postgresql and cockroachdb. This is not the expected behaviour when working with multiple schemas defined in the `schemas` datasource property: users expect all schemas to be reset, moreover migrate dev will be broken if we do not do that, because it expects reset to do its job before re-applying migrations. In this commit, we take into account the namespaces defined in the Prisma schema the migration engine is initialized with. We reset these schemas, when defined, *in addition to* the schema in the search path. The reason we still the search path into account is because that is where we create and expect the _prisma_migrations table to live. I expect we may want to revisit that design choice (issue: prisma/prisma#16565). closes prisma/prisma#16561

* me: implement multi-schema reset on postgres Before this commit, the migration engine `reset` command resets the schema in the search path, on postgresql and cockroachdb. This is not the expected behaviour when working with multiple schemas defined in the `schemas` datasource property: users expect all schemas to be reset, moreover migrate dev will be broken if we do not do that, because it expects reset to do its job before re-applying migrations. In this commit, we take into account the namespaces defined in the Prisma schema the migration engine is initialized with. We reset these schemas, when defined, *in addition to* the schema in the search path. The reason we still the search path into account is because that is where we create and expect the _prisma_migrations table to live. I expect we may want to revisit that design choice (issue: prisma/prisma#16565). closes prisma/prisma#16561 * me: change how multiSchema reset works In multi-schema mode, instead of wiping out the schema from the search path in addition to the schemas defined in the datasource, we now only drop the migrations table in the main schema. This should match migrate dev's expectations around resets.

tomhoule added process/candidate tech/engines/migration engine Issue in the Migration Engine team/schema Issue for team Schema. topic: multiSchema multiple schemas labels Dec 1, 2022

tomhoule mentioned this issue Dec 1, 2022

me: implement multi-schema reset on postgres prisma/prisma-engines#3459

Merged

eviefp added the kind/tech A technical change. label Dec 1, 2022

janpio changed the title ~~multiSchema + migrate: decide whether the _prisma_migrations table living in the search path's first schema is correct~~ multiSchema + migrate: decide whether the _prisma_migrations table living in the search path's first schema is correct Dec 20, 2022

janpio removed the process/candidate label Dec 21, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

multiSchema + migrate: decide whether the `_prisma_migrations` table living in the search path's first schema is correct #16565

multiSchema + migrate: decide whether the `_prisma_migrations` table living in the search path's first schema is correct #16565

tomhoule commented Dec 1, 2022

multiSchema + migrate: decide whether the _prisma_migrations table living in the search path's first schema is correct #16565

multiSchema + migrate: decide whether the _prisma_migrations table living in the search path's first schema is correct #16565

Comments

tomhoule commented Dec 1, 2022

multiSchema + migrate: decide whether the `_prisma_migrations` table living in the search path's first schema is correct #16565

multiSchema + migrate: decide whether the `_prisma_migrations` table living in the search path's first schema is correct #16565