利用hibernate生成的表的别名硬编码的危险以及处理Hibernate: use join table alias on sqlRestriction

2月常规对PaymentApply里不用的关联做了整理，因不易发现，影响了月结而且现在的版本投放指令查询输入金额就会报错
投放申请 对象

 public  class PaymentApply{
        付款凭证(租赁公司)	 
	@OneToOne(fetch = FetchType.LAZY)
	@JoinColumn(name =  "FK_PAYMENT_APPROVAL_GY_ID" )
	 private PaymentApprovalGY			paymentApprovalGY;
	 付款凭证(租赁公司)	  
	@ManyToOne(fetch = FetchType.LAZY)
	@JoinColumn(name = "FK_AIR_PAYMENT_APPROVAL_ID" )
	 private AirPaymentApprovalHK		airPaymentApprovalHK;
	
} 

• 查询逻辑Criteria dc = baseDao.getOrderCriteria(PaymentApply.class, BacklogType.PAYMENTAPPLY);
  这句话的本质是Criteria c = session().createCriteria(clazz);
  比如直接的名称匹配，使用这个别名
  dc.createAlias("paymentApprovalGY", "paymentApprovalGY", JoinType.LEFT_OUTER_JOIN);*
  属性的直接查询
  dc.add(Restrictions.eq("paymentApprovalGY.receiptName", payee);
  sql的查询，使用硬编码
  dc.add(Restrictions.sqlRestriction(to_number(replace(paymentapp2_.REAL_PAYMENT_AMOUNT,',','')) >= to_number('"+ payAmountL + "')"));

• 这里注意paymentapp2_开发人员这样写，是先运行看到sql也就是hibernate生成的表的别名后，再写的硬编码。但是很难知道知道这个是PaymentApply里的哪个关联对象，如果关联对象较多，或者因历史代码原因，当前系统已经不再使用，会在对象里直接删除关联，调整顺序等，这时候paymentapp2_会变成paymentapp3_，因为在编译阶段是不会出错的，所以会有代码谁动谁死的巨大隐患

• 经查阅资料，不再硬编码，消除了隐患
  Criteria dc = baseDao.getOrderCriteria(PaymentApply.class, BacklogType.PAYMENTAPPLY);
  Criteria pdc=dc.createCriteria("paymentApprovalGY", "paymentApprovalGY", JoinType.LEFT_OUTER_JOIN);
  属性的直接查询不变
  dc.add(Restrictions.eq("paymentApprovalGY.receiptName", payee);
  这里用别名
  pdc.add( Restrictions.sqlRestriction("to_number(replace( {alias}.REAL_PAYMENT_AMOUNT,',','')) >= to_number('" + payAmountL + "')")

• 其实对于单表的关系，我们平时喜欢用的this_，也能用 {alias}代替
• 参考资料：Hibernate: use join table alias on sqlRestriction - Java Code Geeks - 2023