PWV Portfolio Feed

To handle failed migrations, one option we have is to roll the migration back.

To do this, we use `prisma migrate resolve` with the `--rolled-back` flag.

There are a lot of different reasons why a migration might fail to apply. 

Perhaps we have added a `unique` constraint on a field where duplicates already exist in the database.

Or perhaps we try to modify some tables with foreign key constraints.

📜 This table has the history of migrations that have been run and what state they ended up in.

In the happy path, we get a migration that applies without issue.

But what happens if a migration fails to apply? In that case, we need to use `prisma migrate resolve`.

We have a migrations folder that keeps the history of changes to our database schema and has the SQL files for replaying all the changes to come to the current shape of the database.

But there's another spot where migrations are tracked: the `_prisma_migrations` table.

`prisma migrate deploy` is what we want to have run along with our app deployments so that any pending migrations get applied to our target databases. 

👉 This is typically not a command that you'll work with much in local development.

We generally use `prisma migrate dev` when we're in development working against our local (or remote) development database.

When we want to deploy our changes to production, we use another command in our CI/CD or deployment pipelines:

This command will do the following:

✅ Add a new migration file in the `prisma/migrations` directory
✅ Execute the SQL in the generated file to apply the change to the database

Let's say we are starting out with a brand new app and a fresh database.

We've got our first model and now we want to turn this into a table in our database.

We also want to have a SQL file that produces this change.

We can get these two steps done in a single command

📊 The most robust way to manage changes to your database schema over time is with migrations.

Prisma Migrate makes this super simple ✅

Let's have a look at some of the most common commands you'll use with Prisma Migrate 👇

If you use SwiftPM – and it doesn't matter if you use our generated projects or not! – you might wanna check out the new Tuist Registry to improve your project's dependency resolution.

We truly believe this can become an essential piece in any Swift developer's toolchain ☺️

The Tuist Registry would not have been possible without the amazing Swift community. We both depend on the Package Registry Service accepted and implemented in Swift 5.7, the amazing Swift Package Index as a source of open source Swift packages, and the Tuist community. So, _thank you_ 💜

However, when you use the Tuist Registry, SwiftPM communicates with our servers and only serves you the versions you need. The amount of data that needs to be transferred and stored on your disk is smaller by up to 90 %! We've seen projects going from 6 GB to 600 MB for their dependencies folder.

So, what _is_ Tuist Registry? It's a centralized place for open source Swift packages. The current status quo with SwiftPM is having to do deep clone of _every_ dependency that you might need. That can be slow, inefficient, and unreliable.

"Welcome to the company we really need you to optimize our database queries"

Say no more

🤫 Prisma Studio is getting some small changes that will bring BIG improvements to your workflow.

Tune in Wednesday, January 29 to find out what's coming 👀

TIL htop can also show zfs arc stats

hahaha 🤫

nice one!

Nah just running a big Postgres instance!