在Golang,我对将下游传递给其他方法和函数的意图相当新contexts.我理解一个如何context工作,如何使用它,它如何保持其价值,它如何与父母context及其行为相关 - 我只是不明白为什么首先使用一个上下文.
在一个更具体的例子中,这是这个问题的实际原因,在我工作的公司中,我们已经确定了一些由于边缘情况而经常发生的长时间运行的查询.
我们决定采取的一个明显的解决方案是,在我们投入时间来解决根本原因之前,我们的约束是杀死超过5分钟的查询.
运行我们的事务的方法接受context最初在API调用中启动的方法.这context一直传递给事务函数.那一刻,我找到了两个杀死该查询的解决方案:
1)使用新的上下文:
发起一个新的 context.WithTimeout(ctx, time.Duration( 5 * time.Minute) )
观察a中的Done频道,go routine并在那里有信号时终止该事务
cancel上下文并按预期提交事务.2)使用Timer:
Timer持续5分钟的时间从逻辑上讲,它们是相同的解决方案,但是,何时以及如何决定是否使用context设定的截止日期或旧的Timer？
我的情况是,使用我们的API的人需要在我的资源中进行部分更新.我理解HTTP明确指出这是一个PATCH操作,即使我们这边的人都用来发送PUT请求,这就是遗留代码的构建方式.
举例来说,想象一下简单的结构:
type Person struct {
Name string
Age int
Address string
}
在POST请求中,我将提供具有所有三个值(名称,年龄,地址)的有效负载,并在我的Golang后端上相应地验证它们.简单.
但是,在PUT/PATCH请求中,我们知道,例如,name永远不会改变.但是说我想改变它age,然后我只是发送一个包含新的JSON有效载荷age:
PUT /person/1 {age:30}
现在我的真正问题是:name如果我们的API的消费者发送包含该name字段的JSON有效负载,防止有意或无意修改使用/更新的最佳做法是什么？
例:
PUT /person/1 {name:"New Name", age:35}
我想到的可能的解决方案,但我实际上并不喜欢它们,是:
在我的validator方法上,我要么强行删除不需要的字段,要么name回复一条错误消息说name不允许.
创建一个DTO对象/结构,它几乎是我的Person结构的扩展,然后将我的JSON有效负载解组到它中,例如
type PersonPut struct {
Age int
Address string
}
在我看来,这将添加不必要的额外代码和逻辑来抽象问题,但我没有看到任何其他优雅的解决方案.
老实说,我不喜欢这两种方法,我想知道你们是否面临同样的问题,以及你们是如何解决它的.
谢谢!