Prisma migrate drops manually created partitioned tables

Bug description

I’m using Prisma ORM for PostgreSQL and trying to partition a couple of my tables so I need modifying my SQL files manually. I used prisma migrate dev --create-only, created partitions tables then ran prisma migrate dev (as this page suggests).

It successfully applies my changes along its own, however after first migration applied the prisma prompts for another migration in which it tries to delete all created tables:

Prisma schema loaded from prisma\schema.prisma
Datasource "db": PostgreSQL database "omnichannel", schema "public" at "localhost:5432"

Applying migration `20220518160933_init`

The following migration(s) have been applied:

migrations/
  └─ 20220518160933_init/
    └─ migration.sql
√ Enter a name for the new migration: ... init2

new migration contains tries to drop partition tables:

  - You are about to drop the `Customer_18` table. If the table is not empty, all the data it contains will be lost.
  - ...

How to reproduce

1. Run prisma migrate dev --create-only
2. Change create SQL file from

-- CreateTable
CREATE TABLE "Customer" (
    "id" TEXT NOT NULL,
    "namespaceId" TEXT NOT NULL,
    "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
    "updatedAt" TIMESTAMP(3) NOT NULL,

    CONSTRAINT "Customer_pkey" PRIMARY KEY ("namespaceId","id")
)

to this:

-- CreateTable
CREATE TABLE "Customer" (
    "id" TEXT NOT NULL,
    "namespaceId" TEXT NOT NULL,
    "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
    "updatedAt" TIMESTAMP(3) NOT NULL,

    CONSTRAINT "Customer_pkey" PRIMARY KEY ("namespaceId","id")
) PARTITION BY HASH ("namespaceId");

CREATE TABLE "Customer_0" PARTITION OF "Customer" FOR VALUES WITH (MODULUS 2, REMAINDER 0);
CREATE TABLE "Customer_1" PARTITION OF "Customer" FOR VALUES WITH (MODULUS 2, REMAINDER 1);

1. Run prisma migrate dev
2. See that another migration will be created after first migration has been applied, which will drop just created partition tables:

/*
  Warnings:

  - You are about to drop the `Customer_0` table. If the table is not empty, all the data it contains will be lost.
  - You are about to drop the `Customer_1` table. If the table is not empty, all the data it contains will be lost.
*/

Expected behavior

It should not drop tables that have been created by custom migrations.

Prisma information

model Customer {
  id          String               @default(cuid())
  namespaceId String
  createdAt   DateTime             @default(now())
  updatedAt   DateTime             @updatedAt

  @@id([namespaceId, id])
}

Environment & setup

• OS: Windows
• Database: PostgreSQL
• Node.js version: 16.15.0

Prisma Version

prisma                  : 3.14.0
@prisma/client          : Not found
Current platform        : windows
Query Engine (Node-API) : libquery-engine 2b0c12756921c891fec4f68d9444e18c7d5d4a6a (at AppData\Local\npm-cache\_npx\2778af9cee32ff87\node_modules\@prisma\engines\query_engine-windows.dll.node)
Migration Engine        : migration-engine-cli 2b0c12756921c891fec4f68d9444e18c7d5d4a6a (at AppData\Local\npm-cache\_npx\2778af9cee32ff87\node_modules\@prisma\engines\migration-engine-windows.exe)
Introspection Engine    : introspection-core 2b0c12756921c891fec4f68d9444e18c7d5d4a6a (at AppData\Local\npm-cache\_npx\2778af9cee32ff87\node_modules\@prisma\engines\introspection-engine-windows.exe)
Format Binary           : prisma-fmt 2b0c12756921c891fec4f68d9444e18c7d5d4a6a (at AppData\Local\npm-cache\_npx\2778af9cee32ff87\node_modules\@prisma\engines\prisma-fmt-windows.exe)
Default Engines Hash    : 2b0c12756921c891fec4f68d9444e18c7d5d4a6a
Studio                  : 0.460.0

[omidh14]

I prefer partitioned tables to be ignored automatically. Who wants to write @@ignore for 30-40 tables.

[omidh28]

Let me know if this works.

Thank you for the reply however unfortunately it did not work and threw this error:

Error: P3006

Migration `20220523185041_init` failed to apply cleanly to the shadow database. 
Error:
db error: ERROR: relation "Customer_0" already exists
   0: sql_migration_connector::validate_migrations
             at migration-engine\connectors\sql-migration-connector\src\lib.rs:272
   1: migration_core::state::DevDiagnostic
             at migration-engine\core\src\state.rs:250