2016-12-02 14:36

@光光哥 单步调试一下,看程序具体的走向,很可能是某个拦截器中有 try catch 之类的吃掉了异常

2016-12-02 13:33

@静静滴疯 方言是对应于某个 ActiveRecordPlugin,而 dataSource 也是对应于某个 ActiveRecordPlugin,对应关系需要使用 configName 来做,在创建 ActiveRecordPlugin 时需要为其指定一个 configName

2016-12-02 13:31

本质就是一个方言设置问题,仔细看下手册

2016-12-02 12:47

@静静滴疯 截图中的字符是 "`" 而不是 "'" ,注意看一下,终级解决方案是单步调试程序,看一下 batchSave() 方法内部用的 Config 对象中的 dialect 到底是什么类型,一目了然

2016-12-02 12:27

不是字符 "'" 而是字符 "`",这个字符是键盘数 1 左边的按钮上的字符,这个是 mysql 专用字符,已经证明了你用的是 mysql dialect,需要改成 PostgreSqlDialect

2016-12-02 12:26

@静静滴疯 看了一下异常,很明显你是将 postgresql 的方言设置成了 mysql 方言

2016-12-02 12:21

多数据源情况,需要为不同数据源设置不同的方言,例如:
dsSqlServer.setDialect(new SqlServerDialect());
pg.setSetDialect(new PostgreSqlDialect());

这样在使用 Db.use(...) 切换到不同的数据源之后, sql 也会被调整

2016-12-02 11:26

还有一种情况注意一下,如果前方有拦截器在拦截请求以后停止了后续调用,则后续拦截器也不会被执行

2016-12-02 11:25

在此拦截器里面添加一个断点,确保是执行的

2016-12-02 10:43

注意看一下这个方法上的 API 文档:
Batch save records using the "insert into ..." sql generated by the first record in recordList. Ensure all the record can use the same sql as the first record.

这个方法用于批量 save 记录,所使用的 sql 是依赖于你的第一个 record 对象来的,而不需要手工提供 insertSql,第一个参数由 insertSql 改为 tableName 即可:
Db.use("post").batchSave("tb_jan_mst", list, num);

2016-12-02 10:38

典型的配置问题,普通 java 项目的类路径有的在 bin 目录下面,而 web 类路径在 WEB-INF/classes 之下,那么在用 main 方法启动的那个时刻用的是 bin下面的 class,而 web被加载时使用的是 WEB-INF/classes 下面的 class

结果就是看似完全一样的类文件,分别来自不同的地方,造成加载异常

又扫描了一下你的贴子,这个异常是说工不到 class 文件,比上面我提到的情况还要基本, Default Output folder 没有配置好而已,看一下手册,里面有详细的图文并茂的配置

2016-12-01 18:23

如果用数据库客户端,例如 Navicat 这种工具查询仍然很慢,那么就先将 sql 调整好,确保 sql 是快的了,再将 sql 移到项目之中即可打完收工了

2016-12-01 18:22

99.9% 的可能性是 sql 本身就慢,定位这个问题很容易,先不用 jfinal 去查库,而是将 sql 放在数据库客户端中手动先查询一下,看查询返回值所花时间即可

2016-12-01 18:15

这件事情的学名叫:mass assignment,是任何框架都存在的事情,即便你用Spring、struts开发,或者用 ruby 语言的 rails框架开发也一样要处理这件事,开发者自己需要处理好,因为web 框架处于后端,在框架层面无法预测你前端页面传过来的哪些字段是需要的,这种“哪些字段是需要的”逻辑属于业务层面的事情

jfinal 在很早期的版本就已提供了极简支持:
1:model.keep(...) 可以在 getModel 以后,指定只保留几个属性,可以一次指定多个,如:model.keep("title", "content")
2:model.remove(...) 也可以移除指定的属性

对于这个问题的探讨,几年前就有了:http://www.oschina.net/question/260040_46570

2016-12-01 17:23

jfinal 在所有操作数据库的地方都用了 finally { conn.close(); } 确保连接被关闭,所以只要是直接使用 jfinal API 操作数据库,都确保了连接关闭

连接可能未被关闭的情况是开发者自行获取 Connection 的情况,例如:
DbKit.getConfig().getConnection() 或者
DbKit.getConfig().getDataSource().getConnection()

上述两类代码,开发者需要自行处理 connection 的关闭,建议一定要在 finally 块之中去关闭

至于贴子中出现的问题,除了上述用户自行去拿 connection 没关的情况,还有一种情况是连接获取的速度快于连接回收的速度,造成连接很快被耗尽的情况,调整下连接池大小,以及程序即可