00:00 Let's create our migration. We're gonna say npx prisma migrate dev. So we're creating our first migration here. It's gonna warn us that we're gonna lose all of our data and drop all of our tables and all of that stuff. So it's just saying, hey, just so you know, and that's fine for us because we're generating this data anyway. So I'm gonna say yes,

00:19 and we're gonna enter a name for the migration. So I'll say init, and that generates our migration, also generates our Prisma client. So here it's saying we generated this SQL file. So let's take a look at that SQL file right here. And there it is. So we create table user, create table note

00:38 with all these constraints and these foreign keys and primary keys and all that stuff. And then we have some indexes that are created for us automatically for our unique fields as well, which is, you know, that's a nice little thing it does for us. But yeah, what's cool about this is because we commit this to the database

00:56 and we're the ones who are actually applying these migration files manually, we say npx migrate deploy as part of our deployment process. Because of that, we can actually make a change to the SQL. So if we decided, you know what, I'm not a super fan of these indexes,

01:16 so we can just delete them. And now they're gone. I don't recommend that, but you totally can. And it will totally work. And it's super awesome that Prisma just generates the SQL and then you can do whatever you like to with it. I have a couple of different deployments that I have done or migrations that I have done where I have manually edited the SQL

01:35 and it was really, really nice to be able to do that. Another thing that it created for us is this migration lock. So this will just make sure that if you are, if you make a change to the schema file that changes your provider. So here, let's take a look at what that would be. So we come up in here and we say, you know what, I want Postgres now.

01:56 Yeah, you're gonna update the migration lock. And then in that process, it'll be like, whoa, we can't just make that change. You can't apply migrations to a SQLite database that changes it to a Postgres database. That's just not how this works. And so you totally can make those types of changes.

02:14 That's one of the benefits of having an ORM is to be able to make those changes. But it's not gonna be as simple as like updating your migration file or your Prisma provider to change the provider. It takes a little bit more work. And I've got a blog post linked in the instructions

02:34 explaining how I migrated from Postgres to SQLite. So you can take a look at that. So yeah, it's actually a pretty simple process. And anytime you make a change to your schema file, so let's say we wanted to add another model here for, whoops, gonna need to name it.

02:50 So for password, then we could say hash is a string. And the, yeah, we'll need to have an ID field here too. So let's stick that there. That's not how I do the passwords later, but we'll get to that in the future. The point is, anytime you make a change,

03:09 you're going to, and you're ready to commit to that change. As you're developing, you can say Prisma db push, and you can just like play around with it locally. But once you're ready to commit, you'd say npx prisma migrate dev again, and that will ask you for a new name for this migration.

03:28 So we'll say password, and that generates a new migration file. And so now we actually have two migration files. And so if you're creating a new database, it will just incrementally apply these migrations so that it's consistent. The other cool thing is if you make a couple migrations and you have a database in production

03:47 that hasn't applied all of those migrations, it keeps track of which migrations have been applied in the database, and then it will apply those migrations that it hasn't had applied yet. And so you can actually look at our database right here, and it has this Prisma migrations table

04:06 that will show you the different migrations that have been applied. That's how Prisma keeps track. Not something that you typically need to work with directly, but that's how it does it. It's pretty interesting. So, and then of course, we can take a look at that migration file. We can make a change as we see fit.

04:25 You wanna make sure that your migration file matches the schema though, because if you were to say, you know what, I don't want this to be hash. I want it to be yada, like whatever, or Yoda maybe, then yeah, you're gonna run into some problems with your database being inconsistent with your schema and your client.

04:43 So you don't wanna like just change everything willy-nilly, but being able to make some incremental changes or valid changes to your SQL migrations can be quite useful. And that is migrations. And as part of the deployment process,

05:02 you'll say npx prisma migrate deploy, and that will deploy your migrations to the database. And I have that as just like part of my regular deployment process, right before I start up the server, I run those deploys. It works really well. So that is how you do migrations with Prisma.