I have a lot of experience using Hibernate to reverse engineer entity classes (Java) from the DB instance, (this process is the 'reverse' of evolving the DB based on writing entity classes). Often, with existing data and processes, it is essential to treat the DB as the single 'source of truth' and create entities based on the DB.
I'm interested in using Prisma (TS/JS), and I've been looking for generators which can generate Prisma schema (which is used to generate entity classes) based on an existing DB (reverse engineering).
Is there a way to reverse engineer the Prisma schema from an existing DB? Are there any known projects to add this functionality?
I believe you're looking for Prisma's introspection feature. According to the Introspection Concept Article in the Prisma docs:
You can introspect your database using the Prisma CLI in order to generate the data model in your Prisma schema.
....
Introspection is often used to generate an initial version of the data model when adding Prisma to an existing project.
The prisma cli command for introspection once you have the database connection set up:
npx prisma introspect
This should update your Prisma Schema file with the existing database tables.
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 started using prisma especially for handling database migrations. It handles that well. But there are many open issues for things that it does not handle well related to queries (biggest are related to queryRaw not always working as expected and with no straight forward way to use postgreSQL Row Level Security). Everything I've found to be a problem related to queries in prsima can easily be done in node-postgres.
I realize from the docs that some of these issues are not a problem in knexjs but prisma has a more feature rich migration setup (automatic and can be customized).
Can I safely use prisma and node-postgres together? If so, how? For example use prisma for schema design and database migrations and use node-postgres for all my query logic?
Yes, you can safely use prisma and node-postgres together.
Your workflow will look like the following:
Create a Prisma Schema to define your models and underlying database tables.
Use the Prisma CLI (the prisma npm library) to run migrations to your database. This will generate the client in node_modules/.prisma/client directory, which you could optionally delete as you won't be using it.
Instead of using generated Prisma Client inside your node application, use the node-postgres library to run queries against the database in your application.
Since you're only using Prisma to make any kind of migration or changes to the database structure, there's no risk of your prisma schema not being synced with your database. On the off chance this does happen, you can always get it back in sync using prisma db pull.
Furthermore, since your application is not going to use Prisma client to connect to the database for running queries, node-postgres will handle the connection pool.
what is the difference between prisma db push and prisma migrate dev ? When should I use one over the other. Docs say that prisma db push is about schema prototyping only and I don't understand what does that mean.
They serve two different environments. The prisma db push is not to be used in your production environment, as stated in the docs
db push uses the same engine as Prisma Migrate to synchronize your Prisma schema with your database schema, and is best suited for schema
prototyping. The db push command:
Introspects the database to infer and executes the changes required to
make your database schema reflect the state of your Prisma schema.
By default, after changes have been applied to the database schema,
generators are triggered (for example, Prisma Client). You do not need
to manually invoke prisma generate.
If db push anticipates that the changes could result in data loss, it
will:
Throw an error
Require the --accept-data-loss option if you still want
to make the changes
Note: db push does not interact with or rely on
migrations. The migrations table will not be updated, and no migration
files will be generated.
The prisma migrate dev is used in you local environment, as explained in the docs
migrate dev is a development command and should never be used in a
production environment.
This command:
Replays the existing migration history in the shadow database in order
to detect schema drift (edited or deleted migration file, or a manual
changes to the database schema)
Applies pending migrations to the
shadow database (for example, new migrations created by colleagues)
Generates a new migration from any changes you made to the Prisma
schema before running migrate dev
Applies all unapplied migrations to
the development database and updates the _prisma_migrations table
Triggers the generation of artifacts (for example, the Prisma Client)
The migrate dev command will prompt you to reset the database in the
following scenarios:
Migration history conflicts caused by modified or missing migrations
The database schema has drifted away from the end-state of the
migration history
If you have any other question regarding this, there is this comparison in the docs explaining when to use one or the other.
From the docs:
Use db push to prototype a schema at the start of a project and initialize a migration history when you are happy with the first draft
Use db push to prototype a change to an existing schema, then run prisma migrate dev to generate a migration from your changes (you will be asked to reset)
So the key for me here, was that only the first time I had to run db push (into a heroku app with heroku postgres). After that, migrations all the time...
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/
Our clients do not have admin access to our web servers and we run MVC , how can i clone an existing DB to fork the data without shutting down the current DB ?. At the moment EF creates the new DB but all the records need to be manually created so we wanted to do a fork.
I suppose i could go through all entities in all tables , detach them all and insert into the DB but is there a nicer way ? As writing that code for 100 tables is not quick even if we use reflection .
The other option of doing a backup and restore is a bit painful as some of the DBs are hosted on SQL server and some as attached files .
Ben
EF is not tool for this. Either use native SQL tools like backup / restore or if there is any additional logic needed create SSIS package or custom ADO.NET application for data migration. With EF it will not only take long to do that but it will be also terrible bad and slow solution.