This week, I'm tweaking column names and adding CRUD functions to the Startchart project.
What I did
Because it's in Typescript, I tried to set type for the parameters, and that makes things easier to change. Example: username: Record['username']
They will look to the Record model for the type, and I only need to make changes in there to change all related parameters.
The CRUD functions are essentially simple exported functions that wrap around Prisma related code to allow developers to not worry about how Prisma works. They just enter the arguments and let the functions do what they are supposed to do.
I tried to write functions to enable basic CRUD operations that will be useful for developers to interact with the database via Prisma.
Part of that was trying to be mindful of how other people might use the functions, so I favored more accessible parameter like username over things like index id that might be more obscured, whenever possible. I also try to be consistent, so it's less confusing, which means I try to ask for the same thing in the parameter, such as username, or id if username isn't available or doesn't' make sense.
Another part of that is to think about whether the name properly explains what the function is supposed to do, such as updateRecordById(), and whether the parameter conveys enough information. I think, if someone sees the functions name and the parameter, they would be able to infer that this is for updating Record model by id, and they need an id and other optional field that they want to change. The parameter is:
(
id: Record['id'],
username?: Record['username'],
name?: Record['name'],
type?: Record['type'],
value?: Record['value'],
description?: Record['description'],
course?: Record['course'],
ports?: Record['ports'],
expiresAt?: Record['expiresAt'],
status?: Record['status']
)
As you can see, optional fields are marked by ?, and they all have type associated from columns in the model. There was a discusion in the team abotu using this as a way to "document" functions, and I hope this does that.
Not everyone is going to be comfortable writing Prisma related code, and it's nice to have reusable code across the project.
I also tried to follow the format of the existing CRUD function for User model, for project consistency.
Experience
It involved a bit of juggling changes, since I want to change column names while also thinking about CRUD operation, so I operated on the assume of my column name changes when I wrote the functions. If I change something in schema, I then have to follow suit in the functions.
The changes got merged, so all is well, and I was able to push the pull request in a timely manner.
Because a lot of people from different part of the development team will be using the database, I also got me thinking about not doing too frequent changes to the schema. I tried to wait to accumulate some non-critical changes and pick a good time (such as before CRUD functions are made available) to make the changes.
Because Prisma client requires you to regenerate every time you change the schema to sync to it, I need to do npx prisma generate a few times (It's a different command for this project due to scripts used). Otherwise, it would not acknowledge the changes and will complain about it. I do notice I have to restart VS code for complain/error to go away even after regenerating the client.
Top comments (0)