盒子
盒子
文章目录
  1. 问题的来源
  2. 问题的解决
    1. 改造添加时的方法
    2. 编辑时的方法
  3. 感悟

记录用户状态

今天主要记录本周开发中遇到的一个问题——记录用户状态。

问题的来源

我们做的产品是某款安检产品的数据集中管理,主要是为了处理AI所需的样本,我们通过web进行标注任务、数据传输任务、设备型号、设备类型、存储源、传输协议等等的管理与分配,以上各种东东的管理(各种简单的复杂的增删改查)是我负责。

那是一个风和日不丽的周一,leader说客户(其实就是某个人脸识别的兄弟部门)需要一项训练集的管理web,毫无疑问的,这个任务是我的。AI嘛,说白了就是不断训练数据,获得模型,再训练,再通过新的数据进行测试,根据结果再通过新数据训练,再得到算法模型,再测试,周而复始的调参。所以训练集必须要好好管理啊。

那么,当我创建一个新的训练集的时候,训练集本身包含5个自有属性,还要通过一个数据包的查询接口来获得的数据包,以上的5个自有属性+这个数据包(不知道有多少,反正是通过另外三个查询条件获得数据包内容)组成一条数据集。

这条训练集数据可以被编辑、被删除、被导出。

编辑的业务场景是:点击编辑时首先通过获得当前项训练集的id的接口来回显数据库中存储的数据,而训练集只有那五个自有属性可以被修改,数据包的内容以及创建时的三个查询条件(也就是创建时的查询状态)不可修改。

基于上面的业务场景,我添加一条新的训练集的时候,该训练集的五个自有属性+数据包+查询状态都应该存储到数据库中。

而一开始与我对接的java后台的数据库中表没有对应字段去存储查询状态,我与之进行第一轮交涉,经过思考,他觉得这样太复杂,因为这个查询条件没有单独的id去存储,需要再建新的数据库表,希望前台来处理这个状态,因为通过数据包的查询接口获得了表征查询获得的所有数据包的一串标识码和数据包总数,他认为我可以通过一个对象记住,然后编辑时再把它关联回去。既然后台要建表,还要建新的实体类,比较复杂,那我前台看看处理下。

可是,我一思考,这个查询条件要与该条训练集绑定才能保证编辑该条训练集的时候回显正常 的数据,也就是说要把查询状态与该训练集的id关联起来, 那么问题来了,添加的时候,并没有id,此id是往数据库存储时后台自动生成的,前台也没法拿到这个id,那么我也没法通过一个对象把查询状态+创建该训练集的id存储起来,好像前台也没法处理。

可是这个任务必须要做啊,我和后台的小伙伴两个萌新大眼瞪小眼。

问题的解决

没办法了,去跟leader商量了,结果人家云淡风轻的说:

  1. 后台在表里面建个searchCondition字段,给它个长点的字符串格式。
  2. 前台创建时把查询条件包装成一个大字符串,数据库就存这个大字符串就行了。
  3. 编辑时前台拿到那个长字符串,再解析,分别把数据回填到查询状态的form里面就行了。

听完之后我俩回来后,讨论了一下就开始干了,有了明确的方向干活就是快啊。

改造添加时的方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
if (action === "add") {
let searchCondition = {
businessType: this.form.businessType,
//时间戳处理,原始处理是new Date().getTime(),应使用其他方法去处理时间戳的问题
uploadTime: this.form.uploadTime,
plotTask: this.form.plotTask
}
axios.post(`${base_url}/trainSet/...`, {
//其他代码
searchCondition: JSON.strinify(searchCondition)
})
.then(res => {
//代码...
})
}

编辑时的方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
showFormData(id) {
let val = {
id = this.form.id,
//...
}
axios.get(`${base_url}/trainSet/getTrainSetById?id=${val.id}`)
.then(res => {
let data = res.data.data
let searchConditionJSON = JSON.parse(data.searchCondition)
this.form.businessType = searchConditionJSON.businessType
//...
//或者直接用解构,通过查询条件再调一遍查询的接口即可获得所有的数据包以及总数目
})

}

感悟

具体问题还是没法深入到代码层面去分析,对于数据库的知识比较匮乏,不知道如何去抽象业务场景。

原来JSON的基本玩法这么玩。

多思考,多请教,多记录。