Results 10 comments of UncleChair

@gqcn Thanks for your reply. But seems `inotify` is not considering solving it since many other projects also meet this problem. Or do you think it is acceptable to add...

@wohenbushuang Thanks for your suggestion! I think to obtain consistence usage of Linux should be a solution. As for my project, it would be ok to just move all the...

@gqcn 强哥好,我个人觉得目前goai模块的主要问题可能还是对于非200状态码的处理不是很理想。诚然在全200状态下文档的支持度已经很好了,但对于非200派的而言实际上还是需要其他状态码管理的,我们非200派维护一些东西会比较拧巴哈哈哈哈。目前添加状态码或者是状态码的具体example都需要进行很长一串结构体的构造,例如下面这个比较丑陋的实现: ``` go func AddResponseStatus(openapi *goai.OpenApiV3, path string, method string, contentType string, object interface{}, status string, description string) { // Add schema openapi.Add(goai.AddInput{ Object: object, }) location := strings.ReplaceAll(reflect.TypeOf(object).PkgPath(),...

@gqcn 感谢强哥的思路,结合源码的一些内容我这边也想了一个关于不同返回状态码数据结构定义的方案: - 添加一个`status` tag 到gtag里 - 在定义返回结构体时直接声明包含`status` tag的字段 - 在goai structToSchema时忽略包含`status` tag的字段 - 将包含`status` tag的所有字段解析并添加为特定状态码下的结构定义 举个例子就是: ``` go type XXXReq struct { g.Meta `status:"201" example:"xxx.json"` Status string `json:"status" des:"server...

> [#3747 (comment)](https://github.com/gogf/gf/issues/3747#issuecomment-2408832814) 定义太多不同的返回数据结构可能确实会造成一些使用上的混乱,其实最好还是在有common response的情况下自动复用,我也是更倾向于直接复用。不过考虑到可能用户的response handler会有定制的错误结构体需求,可能实现一个类似override的流程会更好一些? 目前的构想是当包含 `status` 标签的字段被解析时,如果该字段本身是空的就直接复用common response;如果包含额外的字段就直接优先将该字段解析并覆盖返回结构。或者和原来的逻辑一样,在包含mime标签时直接忽略common response。这样既能满足一些定制化的需求,也能保证在一般情况下的使用便捷。

@gqcn Any update sir? This problem could be serious if any logic is relied on the parsing.

https://github.com/gogf/gf/blob/fee38b4531224b929c095ef643a68a92bbad3d4b/net/ghttp/ghttp_request_param_request.go#L241-L254 @gqcn Missing in query check here, seems related to #4182 ?

typeMapping和框架推荐的一些最佳实践不太一致,例如ORM文档中的: > 我们建议使用`bit(1)`来表示字段的`bool`类型,而非`tinyint(1)`或者`int(1)`。因为`tinyint(1)/int(1)`字段类型表示的范围是`-127~127`,通常可能会被用作状态字段类型。而`bit(1)`的类型范围为`0/1`,可以很好的表示`bool`类型的两个值`false/true`。 而且mapping的做法和各个数据库的耦合很大,不利于后续添加其他数据库驱动,要做gdb migration的话感觉会需要一些基于驱动的映射机制,改动会比较大。 以及GoFrame应该是不会内置migration功能的,很多issue都讨论过这个问题 https://github.com/gogf/gf/issues/3627 要用的话不如试试引入其它的migration项目吧哈哈哈

Migration like Laravel may not be a good idea since it may make database schema unmaintainable (especially some old project with lots of s**t). But indeed migration is helpful in...