使用mvn liquibase:diff未生成dropNotNullConstraint或addNotNullConstraint变更集的问题

我完全懂你现在的困扰——用mvn liquibase:diff对比JPA实体和数据库 schema 时，明明修改了@Column的nullable属性，Liquibase却没生成对应的dropNotNullConstraint或addNotNullConstraint变更集，这确实挺让人头疼的。结合我之前踩过的坑，给你几个排查和解决的方向：

• 先确认Hibernate参考配置的准确性
  你的referenceUrl用的是Hibernate Spring集成方式，这里容易出几个问题：

  • 检查实体类的@Column注解是否正确设置：比如你是不是把nullable写成了null或者拼写错误？比如@Column(nullable = false)才是设置非空，别搞反或者写错参数名。
  • 确认参考URL里的实体包路径是否完整：如果修改的实体不在package.of.my.entities这个包（或者子包）里，Liquibase根本识别不到这个变更。
  • 检查自定义CustomPhysicalNamingStrategy：如果这个策略把实体属性名转成数据库列名时出现了偏差，比如实体里的userName被转成了user_name，但你数据库里的列是username，Liquibase会认为是不同的列，自然不会检测到nullability的变化。

• 显式指定diff要检测的类型
  有时候Liquibase默认的diff检测范围可能没包含nullability（虽然理论上默认是包含的，但某些版本或配置下会有例外），你可以在执行命令时显式指定：

  mvn liquibase:diff -Dliquibase.diffTypes="nullability, tables, columns"
  

  或者直接在liquibase.properties里添加一行：

  diffTypes=nullability,tables,columns
  

  这样强制让Liquibase检测nullability的变化。

• 验证数据库和实体的实际状态差异
  先别着急怪Liquibase，先手动确认差异是否真的存在：

  • 用SQL查询数据库的列状态，比如PostgreSQL里执行：

    SELECT column_name, is_nullable FROM information_schema.columns WHERE table_name = '你的表名';
    

    看看目标列的is_nullable值是不是和你实体修改后的状态不一致。比如你把实体的nullable改成了true，但数据库里该列已经是YES，那自然不会生成变更。
  • 重新编译项目，清理target目录：有时候Liquibase读取的是旧的实体类字节码，清理后重新编译，确保它读取的是最新的实体定义。

• 检查版本兼容性
  旧版本的Liquibase和Hibernate、Spring Boot搭配时，确实存在nullability检测的bug。比如Liquibase 4.0以下和Hibernate 5.4+配合时，可能会漏掉nullability的变更。建议你升级到兼容的版本：比如Spring Boot 2.7+搭配Liquibase 4.15+，或者Spring Boot 3.x搭配Liquibase 4.20+。

• 临时替代方案（如果上面都不行）
  要是实在搞不定自动生成，你可以先执行mvn liquibase:generateChangeLog生成当前实体对应的完整变更日志，然后和之前的日志对比，手动提取出dropNotNullConstraint或addNotNullConstraint的变更片段，加到你的变更日志里。不过这只是临时办法，还是建议把自动检测的问题解决掉。

备注：内容来源于stack exchange，提问作者Vlad Tara