Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Preview feature feedback: Prisma Migrate

See original GitHub issue

Please share your feedback about the new Preview version of Prisma Migrate that was released in v2.13.0 in this issue.

If you encounter a bug, please open a bug report in this repo.
If the feature is working well for you, please share this in a comment below or leave a 👍 on this issue.

If you have any questions, don’t hesitate to ask them in the #prisma-migrate channel in the Prisma Slack.

Issue Analytics

State:
Created 3 years ago
Reactions:8
Comments:56 (28 by maintainers)

Top GitHub Comments

7reactions

thebiglabaskycommented, Dec 16, 2020

The approach we favor the most is to adopt a “forward-only” migration policy where each migration is meant to put the schema in a shape that stays compatible with the previous version of the code so that rolling back the application code deployment is sufficient to maintain the application running without issues. That comes with choosing not to delete columns or tables which hold data in one go, but rather proceed with additive changes instead, or renaming whenever necessary rather than removing completely. Removing columns or tables from production can be fine once the said column or table isn’t used anymore, ideally for some time, and that it doesn’t come at the risk of locking tables accessed a lot, which could put down an application. That is worth removing columns and tables when the risk of removing them is generally low (e.g. traffic to the application is only going to lightly suffer a whole table lock), and the value of reclaiming the storage space is high.

Here’s an article talking about forward-only migrations in practice which gives practical details about that: https://sbg.technology/2016/02/02/how-we-release-so-frequently/

The abstract version of how to proceed is described in this article: https://martinfowler.com/bliki/ParallelChange.html.

You can (and sometimes may inevitably have to) fix a failed migration manually e.g. if it failed halfway through the process, by crafting and running a custom SQL script. While that’s something everyone tries to avoid as much as possible (it’s risky, error-prone, stress-inducing, and usually painful), there is no way to have 100% guarantees that a “down” migrations would nicely get the schema back to its original state without risking to lose data: what if a part of the new version of the application worked and started adding data to the newly created columns? Rolling back would be dropping that data, which can cause users quite some frustration…

7reactions

xiaoyu-tamucommented, Dec 8, 2020

Waiting for nativeType to be supported 😃

Top Results From Across the Web

Prisma Migrate Preview - Database Migrations Simplified

Prisma Migrate generates migrations as plain SQL files based on changes in your Prisma schema. These SQL files are fully customizable and allow ......

Prisma on Twitter: " Here's an example of how you would use ...

What do you do when your schema migration fails? ... Preview feature feedback: `migrate diff` & `db execute` · Issue #11514 · prisma/prisma....

Preview Databases (Feature concept for the Prisma Data ...

In this video, you'll see a demo of an early concept our team is working on to make sure databases are smoothly integrated...

Prisma 4.3.0 Release - GitClear

Before this release, you may have occasionally seen some traces that took 0μs working with the tracing Preview feature. In this release, we've ......

@prisma/migrate - npm

Declarative data modeling & schema migrations ... Prisma Migrate is an imperative database schema migration tool that enables you to make changes ...