Update & UpdatePoint Models

[00:00:00]
>> All right, we're gonna keep moving. So I got products here. Other ones I had were, so we have product. And then, I felt like products have updates, so I made an update model. Users can have products and products can have updates. So that's what we're gonna do.

[00:00:17]
We're gonna make an update model. So let's do that. So I'm gonna go back into here, I'm gonna say model, update like that, you already know I'm copying that ID and that created ad, and I'm pacing it here just like that. I'm also probably gonna add another one here underneath created ad called updatedAt since you might be able to update updates, I guess, that makes sense, and then we'll give that one a date time as well.

[00:00:46]
It doesn't have a default, because I don't know when you updated it. So I'm not gonna give it a default. So we got that. First. Okay, so I think obviously they have a title if we go back and look at the design. The title would be, I got so many of these open, it would be like this thing, that would be the title.

[00:01:11]
So that's why I'm saying, so one of these things is an update. And here's the title for the update. Well, I'm sorry. This whole thing is an update, and one of these things is The title for it. So we have a title, that's gonna be String, and then we have Body which is also String.

[00:01:45]
We have status which is, if you go back and look at design, it's this thing. So like in-progress, things like that. Because there's gonna be finite number of statuses versus bunch of random statuses. I'm gonna use something called enum, so I've never heard of enum before. An enum is basically just like a bunch of constants.

[00:02:05]
That's basically what it is, it's a bag of constants. So I'm gonna say I have an enum called UPDATE_STATUSES and I'm gonna make some, I'm gonna make one called IN_PROGRESS. I'm gonna make another one called, I don't know, SHIPPED, another one called DEPRECATED, And, yeah, and you can make as many status as you want, I probably have something different on the site.

[00:02:38]
But so we got the UPDATE_STATUSES and then for status down here, I can say, your type UPDATE_STATUSES. I guess, I should just call it UPDATE_STATUS, not statuses. And then I can give it a default of one of them. I'll say by default, they're all in progress, Okay? And then I have some other things down here like version String, things like that, so we can add those.

[00:03:16]
So, reason I put versions of to design that there was some updates cell like a version release thing here so I was like we should track the version. So that's what I'm tracking, the release there, so but it's optional, it's not all of them have it, so I can say version, it's a string, but it's optional.

[00:03:36]
By default every field is required unless you put a question mark on it. So optional, and then asset because some updates have an asset. This thing has a GIF. This one also has a GIF. I guess all these have assets but maybe you don't have one for one of them.

[00:03:55]
So, also gonna make that a String cuz it'll be a URL and it's also optional. So you can kind of see just like how I'm going through the design like tryna think about how to model this data. Is actually how I do it in real life, I literally do it this way.

[00:04:11]
I don't know any other way. If you have another way, I'd be super interested in your process cuz I have to do it this way, Okay? And then now an update belongs to a product, so we got to set up that relationship. So let's do that. So we'll have productId.

[00:04:31]
That's gonna be type String, cuz a productId is a String, and that's what we're gonna reference there. And then we have product. And I'm gonna say that's type product And relation of the fields to productId, who references Id like that. So product is type product, has a relationship for the productId field here on the updates side and it references the id on the product side.

[00:05:11]
And we get this squiggly. We can go back to our terminal, we can run npx prisma format. And just like that, if you scroll up to our products, we get this update here. I don't want it to be called capital update, and I want to be plural, so I'm gonna call it updates like that.

[00:05:29]
And then I think I had one more, so I think I just confused myself. The update is actually this whole thing, but these little things, I think I call them update points. They're just like little points and update. I'm not good at naming stuff, so, but I call it update points.

[00:05:44]
So that's what we're gonna do, we're gonna call these update points. And this whole thing is an update. So let's do that. So I'll say model UpdatePoint. And I'm getting all three of these, id, createdAt, updatedAt, putting them in there. And if I look at an UpdatePoint, it has this thing and then this thing, right?

[00:06:09]
So what did I call them here? I think I called them, they got name and description. So let's do that. So name is String. We're gonna give it a length here. And then description is also String but it doesn't have a length cuz it could be longer. So we got that UpdatePoint.

[00:06:40]
And because UpdatePoint belong to updates, we have to set up that relationship. So I'll say updateId is type String and it belongs to an update whose type is update with a capital U and I'm gonna set up a relationship on the fields for updateId that references the id field on update.

[00:07:15]
I'm just gonna run my thing again cuz it's just so nice to me. And, If I go back to my update, you can see it at UpdatePoint, lowercase that and called it points instead and there we go, we have a schema. Any questions on this or just thoughts, opinions on prisma so far for anyone who's ever interacted with a database.

[00:07:41]
>> I love it.
>> You love it?
>> Yeah, my bootcamp is teaching document base like MongoDB but I jumped ahead for my big project I'm building, and so I've been teaching myself PostgreSQL and Prisma has been major.
>> Love it. I love that, yeah. Yeah, it does make working with relational databases less daunting.

[00:08:04]
That's for sure. I kinda briefly looked at their source code. So they have like a translation layer that basically applies to, they have to write a custom adapter for every database. And their translation layer does the communication of that. So it's like they can't just like, we can support any database like no someone mainly has to go in and write that translation layer and that adapter for that specific database and, I mean, I've name the mongo1.

[00:08:29]
It took them months, took them a long time to make so I wouldn't. I think what they did was they went and hired some of the best database experts in the world who worked on these databases, and had them write those adapters. Because I saw at one point, they were working with some of those folks.

[00:08:44]
So yeah, it seems like a very tedious thing, but yeah, it's not like they're definitely considering best practices for each database. Because it's going a database at a time and it's not so much like, just we're gonna spray and pray every database and you're all going and get treated the same.

[00:09:02]
Because even in our documentation, it'll be things like, for instance, we're gonna get to migrations, you don't need migrations on mongo, so you just don't even run them, right, there's like, don't even do on it doesn't make sense. Or things like IDs, you won't need stuff like this in a mongo1, so it's like you don't need these at all, so yeah, they've considered that, and I think they've done a good job.