前言
最近项目中使用Node开发,Nest.js作为框架,TypeOrm连接数据库,期间遇到一些坑,这里记录一下。
问题
1. 插入数据之后返回的ID集合,ID相同
在TypeOrm插入数据库操作的返回结果中,identifiers
字段会是插入数据的id集合,预期情况应该是这样的:
1 | [ |
但实际开发中发现是这样:
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文件,编译速度大大提升。
总结
后端开发和前端开发有很大的区别,各种解决问题思路不同,后端部分还有很多需要我学习的地方。