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

multiSchema: migrate reset only resets first schema #16561

Closed
andyjy opened this issue Nov 30, 2022 · 1 comment · Fixed by prisma/prisma-engines#3459
Closed

multiSchema: migrate reset only resets first schema #16561

andyjy opened this issue Nov 30, 2022 · 1 comment · Fixed by prisma/prisma-engines#3459
Labels
bug/2-confirmed Bug has been reproduced and confirmed. kind/bug A reported bug. team/schema Issue for team Schema. tech/engines/migration engine Issue in the Migration Engine topic: multiSchema multiple schemas
Milestone

Comments

@andyjy
Copy link
Contributor

andyjy commented Nov 30, 2022

Bug description

WIthout multiSchema, migrate reset drops all tables and starts from an empty schema.
With multiSchema, I observe it only "resets" the first schema in the list.

This causes subsequent resets to fail when migrations conflict with the end state of a secondary schema - e.g. you have a migration that renames a table in a schema that isn't the first schema.

How to reproduce

previewFeatures = ["multiSchema"]

schemas  = ["first", "second"]

model Example {
  @@schema("second")
  ...
}

migration.sql:

ALTER TABLE "second"."Example" RENAME TO "NewName";

subsequent runs of prisma migrate reset fail with error relation "NewName" already exists

My impression is this issue is relatively straightforward (not yet implemented) - just let me know if a working reproduction is required.

Expected behavior

No response

Prisma information

Prisma v4.7.0

Environment & setup

  • OS: macOs
  • Database: PostgresQL
  • Node.js version: 16

Prisma Version

4.7.0
@andyjy andyjy added the kind/bug A reported bug. label Nov 30, 2022
@tomhoule tomhoule added bug/2-confirmed Bug has been reproduced and confirmed. tech/engines/migration engine Issue in the Migration Engine team/schema Issue for team Schema. topic: multiSchema multiple schemas labels Dec 1, 2022
@tomhoule
Copy link
Contributor

tomhoule commented Dec 1, 2022

Related: #10043

tomhoule added a commit to prisma/prisma-engines that referenced this issue Dec 1, 2022
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
@Jolg42 Jolg42 added this to the 4.8.0 milestone Dec 1, 2022
tomhoule added a commit to prisma/prisma-engines that referenced this issue Dec 2, 2022
* 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug/2-confirmed Bug has been reproduced and confirmed. kind/bug A reported bug. team/schema Issue for team Schema. tech/engines/migration engine Issue in the Migration Engine topic: multiSchema multiple schemas
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants