GoFrame如何实现顺序性校验

简介: 这篇文章填上之前留的坑,我们以map校验举例:

基本介绍


我们通过上一篇文章了解到:Error接口对象的方法,其顺序性只有使用顺序校验规则时有效,否则返回的结果是随机的。

即使我们使用FirstItem, FirstString()等其他方法获取校验结果也是一样,返回的校验结果不固定。


无序的原因


因为校验的规则我们传递的是map类型,而golangmap类型并不具有有序性(底层数据结构是hashmap),因此校验的结果和规则一样是随机的,同一个校验结果的同一个校验方法多次获取结果值返回的可能也不一样了。


顺序校验


我们来举个栗子:

校验结果中如果不满足required那么返回对应的错误信息,否则才是后续的校验错误信息;

也就是说,返回的错误信息应当和我设定规则时的顺序一致。


代码示例如下:


package main
import (
  "fmt"
  "github.com/gogf/gf/v2/frame/g"
  "github.com/gogf/gf/v2/os/gctx"
)
func main() {
  var (
    ctx    = gctx.New()
    params = map[string]interface{}{
      "passport":  "",
      "password":  "wangzhongyang",
      "password2": "wangyang",
    }
    rules = []string{
      "passport@required|length:6,16#账号不能为空|账号长度应当在{min}到{max}之间",
      "password@required|length:6,16|same:password2#密码不能为空|密码长度应当在{min}到{max}之间|两次密码输入不相等",
      "password2@required|length:6,16#",
    }
  )  
  err := g.Validator().Rules(rules).Data(params).Run(ctx)  
  if err != nil {
    fmt.Println(err.Map())
    fmt.Println(err.FirstItem())
    fmt.Println(err.FirstError())
  }
}


执行后,终端输出:


map[length:账号长度应当在6到16之间 required:账号不能为空]
passport map[length:账号长度应当在6到16之间 required:账号不能为空]
账号不能为空


可以看到,上述的执行结果是满足顺序性的。

我们来总结一下:我们想要校验结果满足顺序性,只需要将rules参数的类型设置为[]string,按照一定的规则设定即可,并且msgs参数既可以定义到rules参数中,也可以分开传入(使用第三个参数)。

rules的这种满足顺序性校验结果返回的规则,我们称之为gvalid tag

下一篇文章为大家剖析gvalid tag的知识点。


总结


通过这篇文章,我们已经拿到了实现顺序性校验的金钥匙:只需要将rules参数的类型设置为[]string,按照一定的规则设定即可,并且msgs参数既可以定义到rules参数中,也可以分开传入。

相关文章
|
SQL 缓存 NoSQL
接口的幂等性设计和防重保证,详细分析幂等性的几种实现方法
本篇文章详细说明了幂等性,解释了什么是幂等性,幂等性的使用场景,讨论了幂等和防重的概念。分析了幂等性的情况以及如何设计幂等性服务。阐述了幂等性实现防重的几种策略,包括乐关锁,防重表,分布式锁,token令牌以及支付缓冲区。
6884 0
接口的幂等性设计和防重保证,详细分析幂等性的几种实现方法
|
3月前
|
设计模式 NoSQL Java
通用框架实践|Pipeline设计+幂等重试
本文讲述在闲鱼同城模块中,针对二手车和租房等业务的商业化需求,设计和实现了一个基于Pipeline模式和幂等性控制的通用框架。
|
20天前
|
消息中间件 存储 Java
深入源码理解MQ长轮询优化机制
【11月更文挑战第22天】在分布式系统中,消息队列(MQ)作为一种重要的中间件,广泛应用于解耦、异步处理、流量削峰等场景。其中,延时消息和定时消息作为MQ的高级功能,能够进一步满足复杂的业务需求。为了实现这些功能,MQ系统需要进行一系列优化,长轮询机制便是其中的关键一环。本文将深入探讨MQ如何设计延时消息和定时消息的优化机制,特别是长轮询机制的实现原理及其在Java中的模拟实现。
32 2
|
4月前
|
缓存 NoSQL Java
接口幂等该如何设计和实现
本文探讨了程序开发中常见的重复操作问题,如多次点击生成多余订单或支付、RPC调用失败后的重试机制滥用及非法重复请求等。通过接口幂等性设计可有效解决这类问题,确保相同请求多次执行结果一致无副作用。文章详细解释了幂等性的概念及其重要性,并提供了具体的设计与实现方法,包括使用唯一标识符、设计幂等操作、事务处理及缓存策略。此外,还讨论了实现幂等性接口所带来的好处,如并发请求处理、失败请求管理及系统集成等,并提出了验证接口幂等性的策略。通过这些技术和方法的应用,可以显著提升系统的稳定性和用户体验。
103 1
|
5月前
|
存储 消息中间件 缓存
中间件最终一致性
【7月更文挑战第15天】
40 1
|
5月前
|
消息中间件
分布式篇问题之通过本地消息表实现分布式事务的最终一致性问题如何解决
分布式篇问题之通过本地消息表实现分布式事务的最终一致性问题如何解决
212 0
|
7月前
|
缓存
什么情景与接口需要做幂等
什么情景与接口需要做幂等
71 0
|
SQL 负载均衡 NoSQL
【防止重复下单】分布式系统接口幂等性实现方案
【防止重复下单】分布式系统接口幂等性实现方案
1766 0
【防止重复下单】分布式系统接口幂等性实现方案
|
SQL NoSQL Java
【项目场景】如何保证接口的幂等性?
【项目场景】如何保证接口的幂等性?
464 0
|
NoSQL Java 数据库
java接口防重提交如何处理
举一个最简单的例子:日常开发中crud在业务系统中普遍存在,在服务端没有做任何处理,客户端没有做节流、防抖等限流操作时,同一秒一个用户点了两次新增按钮,导致数据库中存在同样两条数据,其结果可想而知,同理修改、删除同样的道理;查询本身具有幂等性,但是在同一秒钟同样的操作,查询多次和一次,有区别吗?区别大了去了,不谈用户体验如何,光是网络开销、流量占用、带给服务器的压力等等,生产中一点小的问题,如何不及时处理,可能会引发灾难性bug。