I've been using `introspect` command to update to ...
# orm-help
a
I've been using
introspect
command to update to the schema for the dev env. Now I want to update the schema on the qa env as well. How can I achieve this?
j
What is the problem that you need to solve?
a
so I created a new qa env. Previously I was using only the dev env. Now the qa env doesn't have the table and columns. I'd want to use the schema in the dev to use make the tables and columns in qa.
j
Ah - then you can just use Migrate - either
db push
or create migrations (As files) via
migrate dev
.
(In this case I think going with
db push
should be fine - it will just create your Prisma schema in the database you are connected to)
a
So should I run this command on every github action?
Initially I was not completely familiar with the schema so was creating fields directly in db and doing the
introspect
. Should I run the db push command as ci/cd pipeline?
j
If that is what you want to achieve, you can do that. Depends very much on what your goal is.
Def read the docs on both commands before using them - they do change databases, so quite "dangerous" if there is data in there etc.
a
Is it fine if I do
instropect
on local env and db push on the
qa
and
prod
r
I would suggest using Migrate in this case. You can create a migration from your current tables and then apply the same on QA via
prisma migrate deploy
.
push
on prod is dangerous. Go for
migrate
in this case for both QA and Prod as it’s easier to maintain.
👍 1
a
Thanks. but the build on qa and prod is automated. How to name the migration?
r
prisma migrate deploy
just applies all the migrations from your current Dev to QA. You do not need to name any migrations.
a
Tried migrating but got this error
Copy code
3 migrations found in prisma/migrations
Error: P3009

migrate found failed migrations in the target database, new migrations will not be applied. Read more about how to resolve migration issues in a production database: <https://pris.ly/d/migrate-resolve>
The `20210519144318_changed` migration started at 2021-07-06 12:28:19.900106 UTC failed with the following logs:
r
You would need to follow these steps. First, you need to create the migrations on your development database and then baseline your production. After this is done, you can use
prisma migrate
normally on further migrations.
a
Thanks. I just ran the prisma introspect and the migrate command. I got a different error this time.
Copy code
Error: P3006

Migration `20210519144318_changed` failed to apply cleanly to the shadow database. 
Error:
Database error
Error querying the database: db error: ERROR: type "bigserial" does not exist
   0: sql_migration_connector::flavour::postgres::sql_schema_from_migration_history
             at migration-engine\connectors\sql-migration-connector\src\flavour\<http://postgres.rs:367|postgres.rs:367>
   1: sql_migration_connector::validate_migrations
             at migration-engine\connectors\sql-migration-connector\src\<http://lib.rs:322|lib.rs:322>
   2: migration_core::api::DevDiagnostic
             at migration-engine\core\src\<http://api.rs:89|api.rs:89>
I don't see any bigserial type in the schema.
j
It appears somewhere in the migration you tried to run maybe?
(look at the generated SQL file)
a
Yes. In the old migration file there is a bigserial but not in the current schema file.
j
Should
bigserial
exist on your Postgres database? If so, why does it not? Why is it in your migration file? Can you share that part of your schema and the mgiration SQL?
a
Bigserial doesn't exist in db and schema. Only Integer and BigInt.
id Int @id @default(autoincrement())
Copy code
ALTER TABLE "Facility" DROP CONSTRAINT "Facility_pkey",
ALTER COLUMN "id" SET DATA TYPE BIGSERIAL,
Also it created a migration entry for the table that was dropped previously.
Copy code
ALTER TABLE "Patient" DROP CONSTRAINT "Patient_pkey",
ALTER COLUMN "id" SET DATA TYPE BIGSERIAL,`