当前使用版本(必填,否则不予处理)
3.5.3.2
该问题是如何引起的？(确定最新版也有问题再提!!!)
wrapper是否可以提供类似如下方法
eqx，表示当val为空时则不组装该条件
重现步骤(如果有就写完整)
报错信息3.5.3.2
Comment From: taowater
我自行拓展的时候，对于eqm的实现遇到一些问题，因为拦截请求在PlainMethodInvoker::invoke会合适一点，但是该类是MybatisMapperProxy私有的，拓展性不是很好，改源码会好一点，如果允许，我可以实现提交代码
Comment From: taowater
我翻了一波issue，我觉得维护人员不会有支持这个的打算了，包括in空集合自动查空等一系列更符合直觉的操作。但是我还是想说，这个需求是很常见的，提类似需求的同学也不在少数。可见这并不是一些无理取闹的需求，很多同学包括我的想法也不是要强行把eq默认条件改为值不为空才组装，只是想增加对应的api。有一个维护人员说，提供了notNull的又要提供notEmpty的提供不过来，还是说了一些原因，也确实有道理。但最基本的，字符串为空，集合为空等，还是最常见的判断依据，我并不认为给一份默认支持会有多凌乱，我翻看issue至少有十个人有类似的想法，我觉得这些人的想法至少应该得到尊重，可是我只看到维护人员一遍又一遍地说“自己判空”。我觉得至少有不少人有这种特性需求，至少这个东西应该拿出来思考讨论，我不知道相关维护人员在一次又一次看到提类似想法的时候，难道没有想过《啊这么多人是这么想的吗，是不是可以想一个方案拿出来大家讨论或表决一下，是给一套方法，还是给一份拓展实例》，而不是一昧以维护人员自己的喜好为唯一准则。再退一步讲的话，即使官方不支持，也可以提供良好的拓展机制，让有该类似想法的人可以以较小代价实现相关的拓展，以方便开发人员自行拓展。这也就是所谓拿出来思考之后能给出的解决方案，我可能不知道开源有多难做，只是就这个问题而言，我很不想用一个词：傲慢。在相关issue中我看到的傲慢。我还是支持mp，还是想使用mp的小伙伴有更好更优雅的开发体验。
Comment From: xieliangza
支持
Comment From: Saika77
你说的是那种判断值是否不为空,或者以你自己的布尔条件, true则拼接这个属性进行查询?
Comment From: app2smile
个人意见: 额外提供判空的eq没太大意义. 你都手动写eq了,节省不了什么代码. 要节省代码, 现在的Mybatis生成的动态sql,直接传入构造的实体,不为null的字段进入where中,方法不局限于mybaits plus.
如果想用mybatis plus实现这一点, 个人建议你在你项目中写注解处理器来处理. 个人目前是这么用的,编译期自动生成方法,如:
LambdaQueryWrapper
Comment From: taowater
个人意见: 额外提供判空的eq没太大意义. 你都手动写eq了,节省不了什么代码. 要节省代码, 现在的Mybatis生成的动态sql,直接传入构造的实体,不为null的字段进入where中,方法不局限于mybaits plus.
如果想用mybatis plus实现这一点, 个人建议你在你项目中写注解处理器来处理. 个人目前是这么用的,编译期自动生成方法,如: LambdaQueryWrapper toQuery(Entity t) , 不为null和不为空字符串的字段可以调用方法构造出基本设置好eq的Wrapper. 扩展一下,可以生成很多适合你们框架的查询代码.
因为考虑使用mp有一种常见简单的区分就是，单表使用Wrapper，多表联查自定义sql。在这种理念下，单表wrapper查询可以直观知道这处逻辑是做的怎样的查询，然后对字段判空决定组装确实也是非常常见的逻辑判断的。你说的编译器生成toQuery(Entity t)方法，mp官方其实是可以在entity上各个字段打注解决定该字段的过滤策略的。但这样有两个缺点，一是上文提到的对查询逻辑不够直观，必须去翻阅Entity的字段上的注解内容，二是entity作为数据库直接映射实体，原有一批注解在，这样做会显得entity的定位的阅读复杂化。就是手动写eq，当前的wrapper传递也是有他的优化点的，如果过滤字段稍多一些，就是一排判空了。另外，你的编译期生成是先继承原有wrapper，然后在子wrapper上声明方法再生成吗，如果不是，怎么解决idea报错呢，可以分享一下代码吗？之前在玩山寨lombok，idea的插件项目有点难搞
Comment From: app2smile
写一个自定义注解如@Wrapper, 标注在实体上. 然后自定义注解处理器,在编译期生成一个类如EntityWrapper_, 里面含有此方法. 这不需要解决idea报错, 要做的不是直接改实体,无需搞插件. 本身注解处理器就是为了方便生成新代码文件的, 不建议像lombok那样用注解处理器.
Comment From: taowater
写一个自定义注解如@wrapper, 标注在实体上. 然后自定义注解处理器,在编译期生成一个类如EntityWrapper_, 里面含有此方法. 这不需要解决idea报错, 要做的不是直接改实体,无需搞插件. 本身注解处理器就是为了方便生成新代码文件的, 不建议像lombok那样用注解处理器.
但是生成了还是要调用的吧，还是说你是在方法里反射取这个类 lombok有的人喜欢有的人反对，仁者见仁吧，只是想动手实现一些idear，用不用那是另外一回事了
Comment From: app2smile
不是Lombok不好 是不建议在注解处理器里面修改源文件的语法树, 这不是官方推荐的做法.
LambdaQueryWrapper query = EntityWrapper_.toQuery(new Entity().setXXX().setXXX()). 不需要反射啊
Comment From: taowater
不是Lombok不好 是不建议在注解处理器里面修改源文件的语法树, 这不是官方推荐的做法.
LambdaQueryWrapper query = EntityWrapper_.toQuery(new Entity().setXXX().setXXX()). 不需要反射啊
你这样是要预编译的呀
Comment From: app2smile
注解处理器本身就是在前端编译阶段生成代码,你的问题是什么?
Comment From: taowater
没，提到编译期生成，了解一下你是咋玩的
Comment From: qmdx
wrapper 已经提供前置判断条件，判空并不是唯一的条件，作为底层不会提供这种某个情况的方法，这样的话会有太多无意义的方法出现， eq 的非空你可用实体条件查询 wrapper.lambdaQuery(实体）