MyBatisPlus + Oracle 联合查询排序问题整理，2021 年最后一篇

背景

2021 年说话间就要过期了，今年干的几件事情有：

1. 年初调研了三个任务调度框架。
2. 4 月到 9 月参与了一个产品的开发，SpringCloud + React ，基本掌握了微服务的知识，也熟悉了 React 这个前端框架，惊奇的发现是 React 竟然有 XSS 预防能力。
3. 10 月至 12 月，参与了一个简单项目的开发。

本文整理10 月以来项目开发过程中遇到的简单的技术问题。

数据库操作

MyBatisPlus + Oracle 分页查询及联合查询的知识：

1. 分页查询 IPage 查询中的 OrderItem 排序列名称是数据库表的字段名称，而不是实体字段。
2. DAO 分页查询结果会放到 IPage 入参中，所以方法定义时不需要返回 IPage 对象，直接使用入参即可。
3. Oracle 存储一个中文的长度是 2。
4. Oracle 批量将 byte[] 保存到 BLOB 字段时，不能使用 Union all, 因为它使用 from dual 虚表查询获取数据的方式，因为从虚表取数据字段长度介于2000-4000之间时，Oracle 会将字段类型转为 long 类型，会抛出异常 ORA-01461: 仅能绑定要插入 LONG 列的 LONG 值。
5. Timestamp 类型的字段作为查询条件时，参数传递类型也需要是时间戳。
6. DAO测试，list 列表为空的时候，执行批量插入SQL报异常：java.sql.SQLSyntaxErrorException: ORA-00926: 缺失 VALUES 关键字。
7. 事务提交问题：新开启的事务，下一次查询并没有提交，直到下一次有写操作才提交。但如果查询想得到立即的数据，应该用 select for update。

MyBatisPlus + Oracle 联合查询排序问题

Oracle 区分大小写，多表关联查询时，为了方便映射查询结果，可以设置字段别名，字段别名如果用双引号，需要转义。

例如，这个联合查询 SQL ：

SELECT 'tableA' source,  ID "Id" ,CREATE_TIME createTime
FROM  tableNameA
UNION ALL
SELECT 'tableB' source,  ID "Id"  ,CREATE_TIME createTime
FROM  tableNameB

如果用 createTime 进行排序，因为没有引号，可以直接设置：

orderItem.setColumn("createTime");

如果用 ID 字段排序，由于别名用了双引号，所以需要转义：

orderItem.setColumn("\"Id\"");

React 前端

1. 设置打包目录的方式。
2. Form.Item 表单中的数据初始化，用 initialValue。
3. 函数绑定 this 的方式，显式绑定和 lambda 表达式绑定，以及不绑定 this 出现的事件提前被触发、undefined 等问题。
4. React Table 设置某一列文本显示区域的属性是：align: 'right'。
5. Upload 插件的 beforeUpload 返回 false 或 Promise.reject 时，只用于拦截上传行为，不会阻止文件进入上传列表，如果需要阻止列表展现，可以返回 Upload.LIST_IGNORE 实现。
6. setState 是异步的，如果要在设置完成后执行某些动作可以添加回调函数。
7. 如何获取 Form 表单下 Table 中的表单。

SpringBoot

1. 使用打包插件 exec-maven-plugin 在 prepare-package 阶段阶段已经完成了 class 的编译，如果此时要执行额外的 npm run build 命令将前端工程打包到 resources 目录下，那么最终的 jar 包中是不会包含新生成的资源文件的。所以如果 React 前端工程变化了，首次打包后不会生效。
2. Timestamp 类型的实体，默认生成的 JSON 格式是奇怪的，需要特殊设置格式如：@JsonFormat(pattern="yyyy-MM-dd HH:mm:ss",timezone = "GMT+8")。
3. 不能对 Collections.emptyList() 这个返回对象进行集合操作。

其他

1. word 全局替换：添加换行符号用 ^l。
2. Linux 查找某个进程具体的启动时间：ps -eo pid,lstart,etime|grep PID。

后记

本文算是对今年的一个小结吧，今天在思考一个问题，有没有一种前端页面一劳永逸的数据定制框架呢？就是任何一个需要存储数据、从页面录入数据的工程，React 页面都可以定制数据结构的录入、编辑、回显等基本功能。

因为业务不同，貌似不太容易。想起一个论述母鸡与前端的文章 《母鸡与前端工程师》：

中国是世界鸡蛋第一大国。据统计，2013年全国产量5750亿枚，一个中国人平均一年要吃掉400多枚鸡蛋。
那么中国需要多少只母鸡，才能达到这样的产量？
据说，普通母鸡一年大概生200～250枚鸡蛋。养鸡场里面最优秀的母鸡，一年可以达到320枚。以250枚计算的话，中国至少需要有23亿只母鸡，才能满足全国人民吃蛋的需求。
如果把鸡蛋换成网页，同样的问题就是，中国一年需要生产多少张网页，才能满足人民消费的需要？
去年，我国手机用户超过13亿，智能手机用户超过6亿。就算其中只有一半人上网，那也是3亿多人。这么多人，每天都有几十分钟或者几个小时，要使用手机上网。全体中国人一年消费的网页和App的数量，是一个天文数字。

文章得出一个结论：

鸡蛋是母鸡生出来的，网页从哪里来？归根结底，所有页面都需要工程师做出来。那么多互联网公司，每家公司都需要前端工程师。而全国的前端工程师，目前可能总共有几十万人，对比那么大的内容消费量，肯定是远远不够的（想一想吧，全国的母鸡有23亿只）。这样一想，工程师抢手就不奇怪了。
还有一个很重要的原因，学校不教前端开发，可能会有一些相关课程，但不会系统地教，所有前端工程师都是靠自学的。这也导致了供给偏少。

未来前端工程师会收到 AI 的冲击吗？
如果后端转前端，会不会好一些呢？
——2021 年 12 月 31 日书