当前使用版本(必填,否则不予处理)

3.5.3.1

该问题是如何引起的？(确定最新版也有问题再提!!!)

不算是问题，希望能优化， 1. 当LambdaQueryMapper 链式表达式的时候，如果.eq(sLambda, null) 最后sql里面就是 "column = null"，这个是永远查不出任何结果的sql条件, 希望能考虑，直接转义成 is null 2. 当LambdaQueryMapper 链式表达式的时候，如果.in(sLambda, collection) 如果collection 是空其实此时没必要继续了，直接返回null 或者empty list就可以了，因为此时转义的sql 是 in ()，这种sql是直接报错的

重现步骤(如果有就写完整)

报错信息

Comment From: VampireAchao

感谢您的反馈和建议。针对您提出的两个问题，我们经过仔细考虑，提出以下回复：

  1. 关于LambdaQueryMapper链式表达式中使用.eq(sLambda, null)转化为"column = null"的情况，我们理解这种情况下SQL条件无法查询出任何结果。然而，直接将此转换为is null可能会与现有的isNull方法产生混淆，导致使用者在选择方法时出现困惑。因此，我们建议在这种情况下，用户应当显式使用isNull方法来表达查询意图，以保持API的清晰和一致性。

  2. 对于.in(sLambda, collection)中collection为空导致的SQL转换为in ()，这会直接导致SQL错误。我们认识到，如果在这种情况下自动返回null或空列表可能会更加便利。然而，这样的自动化处理可能会掩盖潜在的逻辑错误，不利于开发者及时发现和排除问题。因此，我们鼓励用户在调用此类方法前自行检查集合的状态，以避免产生无效的SQL查询。

  3. 此外，对现有行为进行修改可能会引入兼容性问题，影响到大量现有代码的正常运行。我们必须考虑到所有用户的使用场景，确保库的稳定性和向后兼容性。

基于上述考虑，我们建议这些情况下的具体处理逻辑应由用户根据具体应用场景自行判断和实现。我们将继续关注社区的反馈，探索可能的改进方法，同时确保我们的解决方案能够平衡易用性和灵活性。

再次感谢您的宝贵意见，我们非常重视社区的每一份反馈。如果您有任何其他建议或疑问，欢迎随时与我们联系。

Comment From: chuanghou

感谢回复

Comment From: chuanghou

那是否可以考虑，equal null的时候抛个异常，因为参数传递了一个null，很有可能本来就是代码编写者没考虑null的情况，所以这种可以考虑抛个异常，让编码者知晓，而不是查出个空的list，以为数据库所有的记录都不等于null