Ryan Shang

生死看淡,不服就干

0%

Node后台开发中使用TypeOrm遇到的问题

前言

最近项目中使用Node开发,Nest.js作为框架,TypeOrm连接数据库,期间遇到一些坑,这里记录一下。

问题

1. 插入数据之后返回的ID集合,ID相同

在TypeOrm插入数据库操作的返回结果中,identifiers字段会是插入数据的id集合,预期情况应该是这样的:

1
2
3
4
[
{ id: 1 },
{ id: 2 }
]

但实际开发中发现是这样:

1
2
3
4
[
{ id: 1 },
{ id: 1 }
]

因为,业务中后面要根据返回的ID值给其他数据做关联,所以返回相同ID会造成异常。

查看了github,有相关issue,但是一直处于open状态:https://github.com/typeorm/typeorm/issues/2131。

最后临时方案是采用在后面操作中,用id+数组index的方式,拼出id。

2. JavaScript对数据库中int和bigint的区别对待

刚开始开发中,线下测试数据库id字段采用int,数据库SELECT操作返回的结果是Number,但是使用bigint,数据库返回的为String,初步猜想是因为bigint的值范围会超过Number,所以采用String。

但是这样会对我们业务产生巨大影戏那个,一方面,DTO校验会无法通过,另一方面,问题1中的业务逻辑会受影响。

经过查找各方文档,解决方案是在数据库连接配置中配置:

1
"supportBigNumbers": false

可以配置这个的原因是我们的业务ID距离Number的上线远远达不到,所以可以用这种方式让

bigint也返回Number。

但是这样配置,TypeOrm插入操作的返回值中的identifiers字段中的id还是String,所以问题1中的处理方式也要对String进行parseInt操作。

3. 数据库版本区别问题

测试上线时,发现功能无法使用,测试环境正常,经过线上测试库分别连接测试定位后,发现还是identifiers,返回的id为undefined

线上数据库版本为5.6,测试数据库版本为5.7。TypeOrm的insert()生成的SQL会有插入id的操作,值为默认值,5.7中可以正常插入,5.6中会插入异常,返回值为undefined,导致报错异常事务回滚。

经过测试,插入数据库操作时,id赋值为null可以解决,后更新上线,因为部署问题无法上线,等待后续上线后检验时候还存在问题。

4. TypeOrm数据库配置问题导致编译慢

项目刚开始开发时,每次本地编辑十分慢,查找文档等发现问题是配置原因,刚开始数据库的entities配置项是这样的:

1
"entities": ["src/entities/*.ts"]

编译时候应该是先会把ts文件编译成js,所以耗时比较久,后改成

1
"entities": ["output/nodeapp/kid-mis-backend/src/entities/*.js"]

直接使用编译后的js文件,编译速度大大提升。

总结

后端开发和前端开发有很大的区别,各种解决问题思路不同,后端部分还有很多需要我学习的地方。