在低代码平台、可视化数据源、自定义报表等场景中经常需要用到用户自定义查询条件
后台根据用户输入的参数生成查询条件
平时程序员硬编码的很简单的条件如WHERE ID = 1 ，其中只有1是可变参数 ID和等号是固定的
但自定义查询条件的场景中ID,等号,1 这三部分全部由用户提供
过程中可能遇到的困难是

• ID可能来自不同的表
  解决这个问题最简单可靠的办法是为用户提供完整的视图，不要让用户自己关联多个表，即使很简单的left关联，对于用户来说也是很难琢磨的，要求用户分清ON,WHERE条件是个很困难的事，
  而且并不是说一遍两遍就能记住的，想想程序员学SQL时用了多长时间才能对SQL没有陌生感，
  再而且用户配置SQL时一定时需要程序员参与的，同样的SQL用到10次，可能需要程序员指导他9次，这样一个工具在用户评价反馈中得有多低能。
  最后即使程序员写的SQL都需要评审，何况用户呢，否则脆弱的数据要面临多大的压力和风险。
• 等号之外的其他比较符号
  对于比较符可以用org.anyline.entity.Compare中的枚举值，这样在后台接收到参数时可以通过Compare.valueOf还原成Compare,直接交给下一步生成SQL，而不需要各种if else
• 值有可能是个数组
  按数量可分为1，2，多个三种情况，这与上一步的比较符有关，对于一些语法严格的数据库，还与列的数据类型有关
  拼接值这一步应该是最繁琐的一步
  

为了解决这个问题我们提供了org.anyline.data.param.ConfigStore来辅助生成查询条件,如用户提交参数key=CODE&compare=in&values=1&values=2
ConfigStore configs;
为了直观的说明用法我们拆开来写
String key;
String compare;
List values或String[]

Compare compare = Compare.valueOf(compare)
configs.and(compare, key,  values)
最后交给service.querys(table, configs)执行查询

在实际开发中拆开写还是有太多的if else要写，如判断key是否为空或是否在表中，values为空时如何处理等各种细节
所以这种机械的判断最好还是交给ConfigStore完成