2017-03-21 21:51

使用拦截器支持事务时，不要将内部的异常吃掉，所以 try catch 中需要将异常再次抛出来，这个可能是在你的代码中没有支持事务的根本原因

此外，还要注意 mysql 只有 innodb 引擎才支持事务，myisam 天然不支持事务，还要注意事务级别是否匹配当前的数据库操作，如果是 jfinal 3.0 版本，默认级别比较高，一般不需要调整

最后，上面的代码中，既然 savePay 中已经使用了 @Before 声明了事务，那么在 enhance 时就不需要添加 Tx.class 这个参数了

最后的最后，个人一般建议直接使用 Db.tx(...) 的方式支持事务，控制起来更加方便，例如，可以 try catch，然后在 catch 中 return false 就可以控制事务回滚了，然后通过得到 Db.tx(...) 方法的返回值再控制对上层响应什么返回值会更方便

关于声明式事务的问题

2017-03-21 16:34

@zhaozhihong sql 中最后的分号去掉没有，注意将 sql 彻底改造成 JDBC 支持的格式

jfinal里怎么执行类似“ALTER TABLE test_TB ADD col_name varchar;”的sql语句？

2017-03-21 15:43

Db.update(sql) 这个应该可以

jfinal里怎么执行类似“ALTER TABLE test_TB ADD col_name varchar;”的sql语句？

2017-03-21 15:12

用一下 renderFile(new File("D:/download/myFile.zip")) 这种形式，可以指定任意路径下的文件，这个在 jfinal 手册中应该有说明

如果没有说明，可以注意一下 jfinal 大部分 API 都会提供相应的重载方法，这些重载方法可以实现不同的需求

关于资源文件的处理

2017-03-21 15:09

对代码进行单步调试，确认一下是哪个地方很慢

JFinal 3.0 集成Shiro支持 对所有action 进行监控

2017-03-21 14:56

@英俊的小铁匠 你的建议已经添加到了改进列表之中，后续如果有两到三个人提出同样的需求会考虑添加该 API，感谢你的反馈

对分页的改进建议

2017-03-21 14:54

@hmgx 输出要等到第 0 秒，不是一开启会有反应，cron 表达式为 * * * * * 的含义一定要清楚

JFinal定时任务调度问题

2017-03-20 21:06

升级到 jfinal 3.0，这个版本已经去掉了对 order by 子句的处理

以前的版本用正则去掉了分页方法中用于查询总记录数 sql 中的 order by 是为了提升性能，因为 select count(*) ... 这类 sql 是否存在 order by 并不影响最终的结果

分页查询的时候order by后面的字符串被截断了？

2017-03-20 21:03

@广州雨人 参考一下这些博文:https://www.oschina.net/search?scope=blog&q=jfinal%20dubbo

关于 jfinal 的 再就业问题

2017-03-20 19:33

有了对比，才会在认知上更有深度，spring 由于过于繁琐庞大、过度设计、配置文件满天飞，所以才会出现 spring boot 这个项目给 spring 做简化工作，而 spring boot 中的很多功能 jfinal 早在五年前就有了，例如零配置、java config 这类概念、热加载，减少代码量等等设计目标

spring boot 本质上是在重走 jfinal 五年之前就开始走的路，但是 spring boot 底层仍然基于 spring 这个庞然大物，开发者看到的仅是浮出海面的冰山，而隐藏在海水之下的山体才是更大的麻烦，所以很多 spring boot 用户在开发过程中会不断要去学习 spring 有关的概念

jfinal 是极简设计，学习成本极低，WEB MVC + ORM + Template Engine 所有功能仅有 400K 左右的 jar 包，比 spring 体系要小得多，所以无论大家是否想用 jfinal 开发，掌握 jfinal 都是很容易并且值得的

关于 jfinal 的 再就业问题

2017-03-20 19:25

@hmgx jfinal 3.0 已经直接支持该功能，参考一下 jfinal 手册有关 cron4j plugin 这一章节

JFinal定时任务调度问题

2017-03-20 19:01

DbPro 的构造是自动的，所以 DbPro.init 这个方法对用户来说是不可见的，正确的构造方法是创建一个 ActiveRecordPlugin 对象，然后启动它，DbPro 自然就被创建好了，后续直接使用即可

如果希望自己动态添加 Config 从而创建 DbPro 对象，正确的流程是将 Config 传给 DbKit.addConfig(config) 方法，然后 DbPro 的创建也是自动的

简单来说 DbPro 对象的管理是动自动化的，所以也就不存在初始化和构造 DbPro 这类问题了

希望能够提供用Config对象而不是configName初始化DbPro的方法

2017-03-20 18:57

@英俊的小铁匠 除不尽的情况是正常的，例如 offset=11，limit=7，就是第二页，因为第一页是 1,2,3,4,5,6,7，第二页是 8,9,10,11,12,13,14，那么 offset=11 处于第二页

对分页的改进建议

2017-03-20 18:54

@英俊的小铁匠 用 offset limit 对于 API 的使用者并不是最方便的，API 的使用者心中多数是安放着自己的需求，例如使用者心中想着想跳到第 N 页，但如果提供的是 limit 那么则需要使用者先计算一次才能使用该 API

对分页的改进建议

2017-03-20 18:51

@abvcb 如果是非浏览器客户端，而是专用的 http 客户端，确实可以直接在 http 协议中体现 PUT、DELETE 这类请求类型，但这样做其实没什么必要，而在 url 中放入请求类型在语义上表达更为明确，站在 API 的使用者的角度看，更容易理解，可读性也更强

从开发实践的角度来说，在代码中必须去指定某 action 为某请求类型，这也会增加代码量，拉低开发体验。抽象资源用什么请求类型映射至某个 action，要么用约定的方式，要么用注解或配置的方式指令，这都会增加学习成本，但却看不到一点好处

JFinal RESTful