I want to delete the prisma service and redeploy but I don't want to lose the data. so should I use prisma delete or prisma reset
I would use prisma delete
But before using this command on production please create database backup. :)
Or better create testing environement.
https://v1.prisma.io/docs/1.34/prisma-cli-and-configuration/cli-command-reference/prisma-delete-ycv9/
Delete an existing service from the Prisma server its running on.
https://v1.prisma.io/docs/1.34/prisma-cli-and-configuration/cli-command-reference/prisma-reset-ycv3/
Delete all service data.
Related
When I changed prisma.schema and run:
npx prisma migrate dev --name init
My Postgres lost all data. Can I run another command which doesn't remove my data? What is best for me in this situation?
From the prisma.io documentation:
Prisma Migrate is an imperative database schema migration tool that enables you to keep your database schema in sync with your Prisma schema as it evolves and
main existing data in your database
Prisma Migrate generates a history of .sql migration files, and plays a role in both development and deployment.
This means that the prisma migrate command is supposed to be syncing the data from the model with the one in the database, adding/removing rows if needed, etc.
Perhaps the command you are looking for is prisma db push? They both have similar uses and aspects, one is for dev, one isn't.
I have a PostgreSQL db that is used by a Nest.Js / Prisma app.
We changed the name of a field in the Prisma schema and added a new field.
Now, when we want to update the PostreSQL structure, I'm running, as suggested by Prisma, the following commands:
npx prisma generate
and then
npx prisma migrate dev --name textSettings-added --create-only
The idea is to use the --create-only flag to review the migration before it is actually made.
However, when I run it I get a list of the changes to be made to the DB and the following message:
We need to reset the PostgreSQL database "my_database" at "my_db_name#cluster.us-east-1.rds.amazonaws.com:5432".
Do you want to continue? All data will be lost.
Of course I choose not to continue, because I don't want to lose the data. Upon inspection I see that the migration file actually contains DROP TABLE for the tables that I simply wanted to modify. How to avoid that?
So how do I run the update without affecting the data?
UPDATE:
I saw that running with --create-only creates a migration which can then be implemented on the DB level using prisma migrate dev, however, in that migration file there are still some commands that drop my previous tables because of some new parameters inside. How can I run prisma migration without deleting my PostgreSQL data?
UPDATE 2:
I don't want Prisma to drop my tables when I just updated them. The migration file generated, however, drops them and then alters them. Do you know what's the best procedure to avoid this drop? I saw somewhere I could first manually update the DB with the new options and then run the migration, so Prisma can find a way to update it, but that seems too manual to me... Maybe some other ideas?
For some cases like renaming tables or columns, Prisma's generated migration files need to be updated if they already contain data.
If that applies to your use case, Prisma's docs suggest to:
Make updates to the prisma schema
Create migration file without applying it (--create-only flag)
Update the migration script to remove the drops and instead write your custom query (e.g. RENAME <table_name> TO <new_name>)
Save and apply the migration (npx prisma migrate dev)
Note that those changes can lead to downtime (renaming a field or model), for which they have outlined the expand and contract pattern.
It might be a Prisma bug: https://github.com/prisma/prisma/issues/8053
I also recently had this situation. It probably should not try to run migration if you only want to create migration file.
But overall it is expected with Prisma to recreate your db sometimes. If you migration is breaking then it will be required to reset the data anyway when you apply it.
I suggest you to create some seeding script so you could consistently re-create the database state, it's very useful for your development environment.
More info
So basically I have my cloud hasura with existing schema, relations tables etc... and i want to offline it using docker and try using metadata export and import that seems not working how can I do it or is there other ways to do it?
this is the docker i want to offline
this is my cloud i want to get the schemas or metadata
OR MAYBE I JUST MANUALLY RECREATE THE TABLES AND RELATIONS??
When using the steps outlined in the Hasura Quickstart with Docker page then the following steps would help get all the table definitions, relationships etc., setup on the local instance just like it is set up on hasura cloud instance.
Migrate all the database schema and metadata using the steps mentioned in Setting up migrations
Since you want to migrate from hasura cloud use the URL of the cloud instance in step 2. Perform steps 3-6 as described in the above link.
Bring up the local docker environment. Ideally edit the docker-compose.yaml file to set HASURA_GRAPHQL_ENABLE_CONSOLE: "false" before running docker-compose up -d.
Resume the process of applying migrations from step 7. Use the endpoint from local instance. For example,
$ hasura metadata apply --endpoint http://localhost:8080
$ hasura migrate apply --endpoint http://localhost:8080
I'm new to Prisma ORM, & I'm trying to make migrations in Prisma
I see that I way to do this is to update data.model & then just run:
prisma deploy
But what if I want to create a migrations for specific versions of app how could I do that ??
As the prisma documentation describes there are two ways of doing database migrations in prisma:
Using the Prisma CLI
Performing a manual DB migration with plain SQL
If you follow the first approach and edit your data model the changes will be carried out automagically once you run prisma deploy. You can specify the service and stage this will be rolled out to via the PRISMA_ENDPOINT environment variable:
PRISMA_ENDPOINT="http://localhost:4466/{SERVICE}/{STAGE}"
This way you can roll out and test you data model changes in a different stage or on a different service.
The second approach is to manually change the database model via plain SQL. Be careful to ensure the database schema and your data model are in sync.
For more information check out:
https://www.prisma.io/docs/datamodel-and-migrations/migrations-POSTGRES-asd4/
I used prisma to generate the schema to a database, but due to changing an id column started getting errors. I deleted the tables and was going to redeploy the schema but I can't find a way to do that.
I've already tried doing things like prisma deploy, but it tells me I'm already sync'd up which isn't true. I need it to redeploy as if the schema was new and it seems to not want to do that.
TL;DR: Try prisma delete then prisma deploy.
Prisma create a database for management where it will hold all migration related data. Even if you deleted the tables manually, you didn't change the migration data about your service. Therefore, Prisma think everything is up-to-date.
Instead of manually deleting the tables, you should use prisma delete to let Prisma do a clean deleting of your tables. Then, you can re-run prisma deploy to rebuild the tables again.
Give this a try: "prisma deploy --force"
According to the documentation you have to accept data loss caused by schema changes with --force. But the tables are already deleted in your case, so I think it is ok to try it.
Prisma doc