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

在查询元数据时经常有一些boolean属性,如是否自增列，是否是货币。 这里其实有3个属性:未知(null)、是(true)、否(false) 因为有些库中没有这些属性，所以经常出现未知(null)的情况 用Boolean虽然可以存储3个值，但在调用时经常会用if()判断这样极易引起空指针异常

无论是什么数据源都会配置一个连接池，在一个命令执行完后，相关的连接会放回连接池待下一个命令复用 这里只是放回了连接池，并没有真正释放连接，也就是没有与数据库断开连接。 只有在注销数据源时，才会把连接池中的连接彻底断开。 但临时数据时没有提供注销的功能，如果需要注销的话应该使用正

这里只是后格式转换部分,插入到word参考【anyline office】，最困难的是前端怎么把这个规则告知后端（大概思路是先定义几种规则让用户来选，比如横向显示什么，竖向显示什么，每行最多几列） 先看源数据 主键

DataSet set = service.querys("表"); set.getMetadatas()会返回列的一些属性，正常情况下只会返回一些基本属性，不会再额外查询列的详细信息，因为那样需要再发起更多的查询，而大部分情况下是不需要列的详细数据的，如列的注释， 如果确实需要可以打开Config

service.querys("table(col1,col2)") <数据源>放在开头 <主键>放在结尾 ds_sso表示数据源 ID,CODE表示主键

DataRow是继承自Map所以Map有的方法DataRow都有， 并且对Map进行了改造和扩展，主要有: 改造了get/set方法，在get/set执行前会先检测key,以实现忽略大小写、下划线、驼峰等格式，效果就是get("userid") get("userId") get("user_id"

定义 D-ORM是NO-ORM中最典型的代表，是一种更高抽象的动态ORM 与传统ORM最显著的区别是: 更高的抽象一切基于动态基于运行时与传统ORM（如Hibernate、Entity Framework等）相比，D-ORM可以在运行时根据用户需求和业务场景，动态生成和执行SQL，而无需编

用的人越来越少就不写了