spring-boot 遺留表的字段命名不符合hibernate規範怎麼辦

處理遺留表是個頭疼的問題。
關於如何處理遺留表名的問題，張喜碩在其Hibernate 自定義表名映射給出了詳細的方案。

注意: 若是是使用的測試數據庫 H2，則重寫命名方法後，也不會生效。這多是因爲 spring-boot認爲若是是啓用的默認 H2數據庫，則無需關注表名或是列表吧。

本節，咱們將在其方案下，解決列名的命名不符合規範的問題。

方案設計

咱們在學習重寫表名時，發現SpringPhysicalNamingStrategy類同時有設置列表的方法。但很遺憾，在重寫列名的方法toPhysicalColumnName(Identifier name, JdbcEnvironment jdbcEnvironment)中，咱們沒法獲取相應的數據表名或是相應的列，固然也就沒法經過獲取數據表名實體的註解，或是列的註解了。

最終方案肯定爲：在想重寫的列上，咱們加入@Column(name = "yz_force_name_xxxx")的相應註解，而後在toPhysicalColumnName(Identifier name, JdbcEnvironment jdbcEnvironment)方法中，對name的值進行判斷，若是包含了yz_force_name_前綴，則進行重寫，不然調用父類的方法

代碼設計

package com.mengyunzhi.check_apply_online.config;

import org.hibernate.boot.model.naming.Identifier;
import org.hibernate.engine.jdbc.env.spi.JdbcEnvironment;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.boot.orm.jpa.hibernate.SpringPhysicalNamingStrategy;

import javax.persistence.Table;

public class DataTablePhysicalNamingStrategy extends SpringPhysicalNamingStrategy {
    private static final Logger logger = LoggerFactory.getLogger(DataTablePhysicalNamingStrategy.class);
   
    /**
     * 重寫父類生成列名的方法
     * @author 河北工業大學夢雲智開發團隊 panjie
     */
    @Override
    public Identifier toPhysicalColumnName(Identifier name, JdbcEnvironment jdbcEnvironment) {
        logger.debug("判斷是否進行字段名稱的重寫");
        Boolean override = false;
        Identifier realName = null;
        String columnName = name.getCanonicalName();
        if (columnName.length() > 14 ) {
            String suffix = columnName.substring(0, 14);
            if (suffix.equals("yz_force_name_")) {
                String realColumnName = columnName.substring(14, columnName.length());
                realName = new Identifier(realColumnName, name.isQuoted());
                override = true;
            }
        }

        logger.debug("重寫，則返回重寫後的名稱，不然調用父類");
        if (override) {
            return realName;
        } else {
            return super.toPhysicalColumnName(name, jdbcEnvironment);
        }
    }
}

總結

處理歷史遺留問題，雖然頭疼，但也迫使咱們開動腦筋。同時，也在無形中，更加了解了面向接口開發的靈活性。更重要的，它告訴了咱們：必定要規範，必定要約定大於配置，必定要使本身的代碼在成爲歷史時，能少些問題。

約定大於配置！