本周，我是tweaking column names和adding CRUD functions到Startchart项目。

我做了什么

因为它在打字稿中，所以我尝试为参数设置类型，这使更改更改。示例：username: Record['username']
他们将寻找类型的Record模型，我只需要在那里进行更改即可更改所有相关参数。

CRUD函数本质上是简单的导出功能，可以围绕PRISMA相关的代码，使开发人员不必担心Prisma的工作原理。他们只是输入参数，让函数做他们应该做的事情。

我试图编写功能来启用基本的CRUD操作，这对于开发人员可以通过PRISMA与数据库进行交互非常有用。
其中的一部分是试图注意其他人如何使用这些功能，因此我更喜欢像username这样的更容易访问的参数，而不是诸如index id之类的东西，这些内容可能会在可能的情况下更遮盖。我也尝试保持一致，因此它不那么混乱，这意味着我尝试在参数中要求相同的内容，例如username或id，如果username不可用或不可用，则'是有道理的。
其中的另一部分是考虑名称是否正确解释该功能应该执行的操作，例如updateRecordById()，以及参数是否传达了足够的信息。我认为，如果某人看到函数名称和参数，他们将能够推断出这是为了通过id更新Record模型，并且他们需要id和其他要更改的可选字段。参数是：

(
  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']
)

您可以看到，可选字段由?标记，并且它们都与模型中的列相关联。 Abotu团队中有一个障碍，使用此方法作为“文档”功能的一种方式，我希望这样做。

并不是每个人都喜欢编写Prisma相关的代码，并且在整个项目中使用可重复使用的代码很高兴。
我还试图遵循用于项目一致性的用户模型现有CRUD函数的格式。

经验

它涉及一些杂耍变化，因为我想在同时考虑crud操作的同时更改列名，因此我在编写功能时操作了我的列名称的假设更改。如果我在模式中更改某些内容，那么我必须在功能中效仿。
更改合并了，所以一切都很好，我能够及时推动拉力请求。

由于开发团队不同部分的很多人都会使用数据库，所以我也让我考虑不对模式进行太频繁的更改。我试图等待积累一些非关键变化，并选择一个美好的时光（例如，在可用CRUD功能之前）进行更改。

因为Prisma客户端要求您每次更改模式以同步的架构进行再生，所以我需要几次进行npx prisma generate（由于使用的脚本而导致该项目的一个不同的命令）。否则，它不会承认这些变化，并会抱怨。我确实注意到我必须重新启动VS代码，以便投诉/错误即使在再生客户后也会消失。