由于元数据的查询需要许多SQL,所以默认情况下会生成缓存。 当通过service.ddl()修改数据库时，缓存会刷新，但通过其他方式修改数据库时，缓存无法接收通知，所以会导致缓存与数据库不一致的情况 为避免以上情况，可以 1.数据库修改都通过service.ddl()执行 2.数据库修改后调用系统接

SELECT * FROM CRM_USER WHERE ID = :ID  以:标识的执行时直接替换  以::标识的执行时以?占位   NAME LIKE :NM + '%'   (NAME = :NM)   NAME = ':NM'   NM IN (:NM)  

在实现元数据管理时经常需要显示数据类型的长度 在Column中有三个相关于属性 length：一般用来表示varchar类型长度 precision：一般用来表示数字类型总长度 scale:一般用来表示小数据点位数 但有些特殊情况，部分数据库的部分类型既有length也有precision 这

public static boolean IS_ENABLE_COMMON_JDBC_ADAPTER= false;   // 是否开启默认的jdbc adapter(仅支持部分标准SQL)遇到没有实现adapter的数据库时可以开启 默认情况下是禁用的，也就是说如果

默认情况下update方法只会更新值有变化的列，可以调用DataSet(DataRow)的 clearUpdateColumns或者  addAllUpdateColumns 更新除了主键之外所有的列

在代代码，运行时自定义场景中，经常会调用不同的方法生成多个ConfigStore也就是多组查询条件 但在调用service.querys时只能接收一个ConfigStore 解决方式： 生成一个ConfigStore 在合成查询条件时把ConfigStore作为参数输入，通过

应用场景:同一个输入框中输入用户编号或用户姓名或手机号都可以查到指定用户,以上参数会通过同一个key提交到后台

对于标准的url格式 /list?id=1&id=2 以及标准的json格式 {id:[1,2]} 可以通过condition("ID:[id]")的形式接收 对于非标准格式如 /list?id=1,2 可以通过condition("ID:[split(id)]")的形式接收 最终都是生成SQL  WHERE ID IN(1,2)

应用场景如 订单集合中有user_id，需要根据user_id到users集合中关联中user_name 如果通过SQL实现大概是这样 SELET O.*, U.NAME AS USER_NAME FROM MM_ORDER AS O LEFT JOIN CRM_USER AS U ON M.U

进口数据多个国别，多个年份，原始结构如下 ID 年份 国别 品类 金额 1 2001 法国