@miemieYaho 请不要立即关闭未经issue发起人确认已解决的issue可以吗? 你们认为已经解决了的, 不一定是真的解决了, 可以等待个3-5天, issue发起人没有异议或者没有任何回复时再关闭issue. 不然就是暴露出了问题, 假装解决了, 发起人这时候大多也懒得再开一个新的issue, 就当他解决了. 这种虚高的issue close量有助于打造更高质量的代码吗?
当前使用版本(必填,否则不予处理)
3.4.3.4 #4135里有人回复说是因为long型主键填充不生效导致不建议用原始类型做主键. 但是我实测3.4.3.4这个版本, int, long这俩原始类型做主键往mysql插入数据, 主键填充都是生效的, 主键填充不生效这个问题已经不复存在. 然而我的那个issue被你们关了, 可问题并未解决, 我只能重开一个issue了.
该问题是如何引起的？(确定最新版也有问题再提!!!)
实体类主键如下
@TableId(type = IdType.AUTO)
private int id;
spring boot启动时, 日志中会打印
This primary key of "id" is primitive !不建议如此请使用包装类 in Class
为什么使用warn级别呢? 会造成mybatis-plus的某些功能用不了吗?
我的实体类一般是能用primitive类型就用primitive类型, 避免NPE.
之前一直用的spring data jdbc, 当使用primitive类型时, 它是按 id = 0来区分是不是已经save过一次了.
按说java的NPE这么多, 不是应该提倡使用原始类型吗? 如果对mybatis-plus没有功能上的影响, 建议这条日志去掉
重现步骤(如果有就写完整)
实体类自增主键如下设置, 然后启动spring boot
@TableId(type = IdType.AUTO)
private int id;
报错信息
Comment From: mabyoung
摘自阿里巴巴开发手册：POJO 类属性没有初值是提醒使用者在需要使用时，必须自己显式地进行赋值，任何 NPE 问题，或者入库检查，都由使用者来保证。 个人看法：id=0和id=null还是有区别的，id=null更符合直觉。比如，对于id自增情况，在使用mybatis-plus进行save 时，你给id赋值为null表示需要数据库来生成id。如果save成功，mybatis-plus会将数据库生成的id返回给你。如果save失败，你的id就还是null。
Comment From: ltbyun
摘自阿里巴巴开发手册：POJO 类属性没有初值是提醒使用者在需要使用时，必须自己显式地进行赋值，任何 NPE 问题，或者入库检查，都由使用者来保证。 个人看法：id=0和id=null还是有区别的，id=null更符合直觉。比如，对于id自增情况，在使用mybatis-plus进行save 时，你给id赋值为null表示需要数据库来生成id。如果save成功，mybatis-plus会将数据库生成的id返回给你。如果save失败，你的id就还是null。
你这就单纯的是你以为, 要真是这样, valhalla这个项目还有存在的必要性么?
Comment From: Muyangmin
同问，项目中使用 Kotlin，主键明确声明 Long (即不可空)，压根不会存在 null 的可能性，也不等同于Java的基本类型。但是启动时一直报这个警告，表越多日志越多:sweat:
Comment From: jptx1234
依稀记得很久之前踩过这个坑，你把IdType设为ASSIGN_ID试一下，别用AUTO，因为AUTO依赖数据库自增，即AUTO的主键填充是数据库做的不是框架做的。而ASSIGN_ID等类型是在框架层根据用户配置的各种ID生成算法去生成的，才是真正的主键填充。
我们当时遇到的坑是：我们的某张表的id要求使用一个固定的算法来生成，于是某位大哥把IdType设为ASSIGN_ID，但代码中的字段是基本类型long，测试时出来的id全是0，大哥一度怀疑我们的id生成算法有问题，排了好久，后来把字段改为包装类型的Long就好了。
如果框架这里后面真的要改，我建议不要去掉这个warn日志，可以把判断条件加的更严格些：当IdType配成了非AUTO和非NONE的时候，才打这个warn出来，因为这个时候用户是真的想使用主键填充功能，但此时字段类型是基本类型，所以主键自动填充会失效，这个warn提示就会很及时。
Comment From: ltbyun
@jptx1234 这个你们为什么会排查好久, id=0, 那就是insert前没有setId啊. 直接在idea中ctrl+鼠标左键单击setId方法, 逐一查看在insert前有没有set不就好了? mybatis-plus顶多有可能在碰到ASSIGN_ID时, 去检查一下id是不是为null, 为null就不insert. 但是你们已经insert到表里了啊, 难道mybatis-plus还会去改你的ASSIGN_ID的值不成, 这不可能啊 搞错了, 原来ASSIGN_ID你们搞的自动填充, 那不就是这样了么, 文档里写的那么清楚, 这也能怪日志没提醒吗?
Comment From: jptx1234
@bthulu 所以其实就是我们那个大哥搞错了啊，类型设成了基本类型long，框架肯定已经在日志里报警告了啊，但是很多程序员习惯很不好，不看警告，包括那个大哥。很多人的习惯就是，服务只要启动成功了，那么启动过程中的日志是没人看的，什么时候开始测功能时，才tail -f 日志文件去看日志，所以一群人都忽略了这个问题。一直到最后，问题才转到我这边，我看到了框架打的warn日志，就知道这里肯定不对劲，所以才对这个问题印象深刻。