2016-08-17 14:43
即便在 baseModel 中生成了这个序列化版本 ID，对你的最终 Model 并无影响，你的最终 Model 在继承 BaseModel 以后，还是要生成序列化版本 ID，否则仍然还是会警告，这时你有两个选择，一个是在最终的 model 中生成它，二个是学习 baseModel 去除警告
根据 jfinal 的极简原则，如果做一件事起不到作用，那还不如不做。此外如果不生成还可以享受 java 生成默认序列化版本 ID 值的好处，这样当 baseModel 随着表结构演化以后，版本也随之变化，避免版本出错
2016-08-17 11:22
@韦甩甩 感谢支持 jfinal 发展，多多关注社区动态，近几天社区会有很大改进
2016-08-17 11:20
@韦甩甩 fastjson 转 json 时，会对所有的 getter 方法进行处理，会将这些 getter 方法的返回值进行转换，这里的 getter 是指 public Type getXxxx() 这种 public 无参 get 方法，如果有参则不是 getter，这个是 java bean 规范
2016-08-17 10:26
@Lintel 感谢分享，个人头像换一下啊，支持下社区发展
2016-08-17 09:50
把原来老版本的使用 HashMap 的 CaseInsensitiveContainerFactory 也一同分享出来哈 ^_^
2016-08-16 23:37
@IvyHelen jfinal 升级都很平滑，一般只是改改方法名即可，内核非常稳固，自第一个版本以来几乎没变动过内核架构
2016-08-16 23:33
JsonKit 之所以不会出现这个问题，有两个原因：
1：JsonKit 转换json 时不会调用 model 的 getter 方法，所以 getter 方法中如果存在数据库操作也不会被触发
2：JsonKit 中有 convertDept 变量能在出现循环依赖时跳出转换
2016-08-16 23:31
从两个方向检查一下：
1：Goods 这个类里面有没有 getter 方法是再次查询了数据库的
2：Goods 内部的对象有无循环关联
总的来说，造成这个错误的原因是被转换的对象之间出现了循环依赖，尤其是上述1中的getter 方法读库，并且依赖关系藏在数据中
上述2中的可能性小些，因为 fastjson 应该对内存中的依赖可以自动处理好
2016-08-16 23:25
order by 应该是不支持问号占位的，所以这个问题或许不存在
2016-08-16 15:21
简单来说这就是一个单元测试的准备工作问题， jfinal 的大部分插件是可以独立运行起来的，唯一的不同是需要自己调用一下这些插件的 start() 方法，在 JFinal web 项目中这个 start() 操作是 jfinal 主动回调的，但在单元测试时 jfinal 无法感知到，所以无法回调
2016-08-16 15:19
jfinal 2.2 手册 5.13 小节为《非 web 环境下使用 ActiveRecord》，参考这部分内容在单元测试的准备方法中启动一下 ActiveRecordPlugin 即可，相应的 EhCachePlugin 也是同样的启动方式，即手动调用一下：ehcachePlugin.start() 方法
