Lombok插件让开发变得更便捷,也带来了很多潜在的问题,如果不去了解Lombok插件的工作过程,就可能会出现很多难以预料的问题。
在xml中创建一个mybatis的简单查询:
<select id="queryElectronSmsSendInfoListByPage" resultType="com.meituan.it.finerp.contract.electron.entity.ElectronSmsSendInfo">
select oessi.id as id,
oessi.lapsed as lapsed,
oessi.last_send_time as lastSendTime,
oessi.receive_mobile as receiveMobile,
oeci.title as contractName
from okc_electron_sms_send_info oessi
left join oeci on oessi.contract_info_id = oeci.id and oeci.deleted=0
where oessi.deleted =0
order by oessi.last_send_time desc
</select>
ElectronSmsSendInfo结构如下:
public class ElectronSmsSendInfo {
/**
*
*/
private Long id;
/**
* 电子合同记录id
*/
private Long contractInfoId;
/**
* 合同单据编号
*/
private String billNumber;
/**
* 合同单据版本
*/
private Integer billVersion;
/**
* 合同编号
*/
private String contractNumber;
/**
* 对应类别枚举,供应商/客户
*/
private Integer partnerCategory;
/**
* 交易方id,如果是供应商,则对应supplier_id(与供应商门户对应)
*/
private String partnerId;
/**
* 企业名称
*/
private String companyName;
/**
* 接收者手机号
*/
private String receiveMobile;
/**
* 短信内容
*/
private String messageContent;
/**
* 最后一次发送时间
*/
private Date lastSendTime;
/**
* 是否失效
*/
private Boolean lapsed;
/**
* 失效时间
*/
private Date lapsedTime;
/**
* 删除标记
*/
private Boolean deleted;
/**
* 最后更新人 emp id
*/
private String lastUpdatedBy;
/**
* 创建人 emp id
*/
private String createdBy;
所以建立的查询并不是全查询。
如果在实体类上加@Bulider注解的话,在编译完成之后会自动生成全参的构造方法。
而mybatis在根据反射向实体类注入数据的时候,如果实体类存在全参的构造方法,那么mybatis会优先根据构造方法进行注入。
而这个过程用代码表示大概过程如下:
/*
* constructParams是构造参数列表
* resultSet是mybatis查询结果列表,当不是全查询的场景下,
* constructParams的长度是大于resultSet的,
* 所以下面这个方法会发生下表越
* 界异常ArrayIndexOutOfBoundsException
*/
public void injectEntity(Object[] constructParams, Object[] resultSet) {
for(int i = 0; i < constructParams.length; i++) {
resultSet[i] = constructParams[i];
}
}
因篇幅问题不能全部显示,请点此查看更多更全内容