00:00 Let's talk about migrations. So making changes so far, what we've done is we just ran npx prisma db push. And that just says whatever the database is right now, the schema is going to like be pushed up to the database. And that works okay for non-breaking changes. So let's talk about that.

00:19 Here we have an order, and then we decide we want to have reviews on the order. So the order table doesn't actually get changed with this. We, in fact, we're only creating a new table. So doing npx prisma db push, that's going to work just fine, no problems whatsoever. Even with existing data, we're not going to break anything

00:37 because there's no change to existing data. There's no requirement for that existing data to change. However, what if we had our user model, we decide our username wasn't unique. We decide, oh, that's got to be unique now. We may have some users in there, multiple users that have the same username. That's a breaking change.

00:55 Or maybe we decide we want the name, which was originally optional to be required. There are probably some users that don't have a name in there. That's a breaking change. This is where npx prisma migrate deploy comes in really handy. And what npx prisma migrate deploy does

01:12 is it will create a bunch or an individual, every time you run it, it will create an individual migration file. And so here's what my website migration directory looks like after I've done a couple of migrations. So you've got your init, and that's going to have a migration SQL, where it has all those create table calls

01:31 and alter tables and whatever else it's going to have. And then we've got a change that I made. I wanted to add user roles. And here I've got some stuff that I wrote manually. So for my own site, I have my own account, and I wanted to make myself an admin.

01:50 And so I set the admin email, or I said update user set role to the admin role, where the email is me at kensydots.com. So I made myself an admin. And yeah, it's actually pretty cool because it generates this SQL that gets committed to source control.

02:10 You end up being able to make whatever changes that you want to as part of the migration. So for making the username unique, that's a little bit trickier, but at least for making the name required, you could just have something that said, select all the users, set their name to be something that's required, and then poof, that works.

02:30 Now at a certain scale, that doesn't work super, like extremely well, but for most of what we're building, that will work just fine. Once you get to a certain scale with some of these breaking changes, you'll probably be better off following the widen than narrow approach

02:49 for those types of breaking changes. So the widen than narrow approach basically says you first widen the app to consume A or B. So let's say that you've got a situation where you're trying to change a name field to a first name and a last name field.

03:08 And so what you do is you widen the app to be able to consume both the last name, name, and the name field. So it can consume any of those things. So all the new code that references first name and last name fields should be able to fall back to the old name field as an example there.

03:28 And that first name, last name should start out as optional, because you've got existing users that cannot do that. And then you widen the database to provide A and B, and the app to write to both A and B. So you add those fields as optional fields,

03:48 and then the app will write to both fields. So the user submits their name, you write to the first name, last name, and the old name field. And then you narrow the app to consume to the first name and last name fields. You no longer consume or fall back to the name field

04:08 now that all the data's been updated. And then you ultimately narrow the DB to provide just B. So in this case, that would just be the first name and last name fields, and then you can safely delete the name field. So this is a pretty common practice for doing zero downtime migrations,

04:26 which is, none of us want to have downtime in our apps. Our users expect us to be better than that. So with that then, the last question that people often ask is, what about push versus deploy? You've got npx-prisma-migrate-push, or db-push, and then npx-prisma-migrate-deploy.

04:47 So you use push when experimenting locally, just you want to push changes, and like, I want to change this field. What does that do? And like, how does that feel? And then when you're ready to commit to something, you use migrate, and it works great. So I think we're ready to do our first migration, and it's going to be awesome. There will be a number of migrations that we make

05:05 in the workshops starting here and going forward. So you will be making some migrations. But for this exercise, we're just doing the initial migration. So it'll be pretty quick, but I think you'll have a good time anyway. So thank you for joining me on this adventure in migrations.