2016-09-02 10:23
@chenwang 聪明的人解决问题，智慧的人消灭/避免问题，愚蠢的人制造问题。就好比 Hibernate 制造了无数的问题
2016-09-02 10:21
主键名可以是任意合法名称，不一定是 "id"
如果是 Model ，需要在 arp.addMapping(tableName, idName, modelClass) 时指定这个 idName，如果使用 jfinal 2.2 生成器，会自动生成映射，不需要处理
如果是 Db.find 的形式查询，需要在查询的时候临时提供 idName，例如：Db.findById(tableName, idName, idValue)
2016-09-01 15:41
@绝望的八皮 主要看一下这个版本的 changelog: http://www.oschina.net/news/69461/jfinal-2-1-released 注意一下这个 changelog 中谈到的 paginate 方法的改进可以忽略，因为 select 与 sqlExceptSelect 合并的这个改进，在后面的版本中被证实并不好，所以又改回去了
2016-09-01 15:39
@绝望的八皮 更新其实很简单，就是将 jfinal 升级到 2.2，基本上就都是一些改改类名，方法名的事情，将 jfinal 版本号改为 2.2 以后，按照 eclipse、IDEA 错误提示的地方分分钟就改完了
2016-09-01 15:12
@小鑫要宵夜 如果 controller 里面 try catch，只要再接着向上抛出被捕获的异常，拦截器仍然可以收到，如果吃掉异常不抛出来，上层就接收不到了
2016-09-01 15:03
@海哥 假定字段是 int(12)，这种情况本身就对应了 jdbc 的 Long 型，难道干预并转换？ 其实干预也不难，在生成的 BaseModel 中的 getter 方法中这样 return getNumber(attr).intValue()
2016-09-01 14:36
前面谈到setter、getter 的参数或返回值类型确实 Long 是指 int(n) n>11 以及 unsign int(11) 的情况，所以是合理的
2016-09-01 14:35
@小飞象 除了在 sql 使用 sum count 会让 int 升级为 long 以外，还要注意以下升级的情况：
1：int(n) n > 11 的情况
2：int(11)，但是是 unsigned 无符号整型的情况
综上，你前面谈到的“表ID字段为转成Long“ 并不是本质原因
做到统一恐怕是不合理的，因为无法兼顾到数值溢出的情况，尤其是 getter、setter 返回值或参数升为 Long 的原因是确实类型就该是 Long
2016-09-01 12:09
查询的时候，可以这样： Db.queryLong("select count(income) from account").intValue();
2016-09-01 12:09
针对这样的升级，可以使用 getNumber(attrname).intValue() 来获取，这样就不可能出错
2016-09-01 12:07
我猜测 t_intercity_trip 第一个字段的类型不是普通的 int、varchar 之类的，很可能是这些类型的一种：binary, varbinary, tinyblob, blob, mediumblob, longblob
2016-09-01 12:04
@l745230 即便是这样的查询也最终可以追溯到某个字段，因为 select count(1) 是针对这个 sql 得到的第一个字段进行的 count 操作
所以根据后面的 FROM t_intercity_trip c 就可以知道这个 count(1) 是指 t_intercity_trip 表的第一个字段，找到这个字段，看下它的类型就知道原因了
2016-09-01 12:01
如果 sql 中针对 int(11) 的字段进行了函数操作，jdbc 为了防止数值溢出，会将 Integer 转成 Long 型，例如：
1：假定有个收入金额字段 int(11) income
2：select income from xxx 这类查询不会将 int 升级为 long
3：select sum(income) form xxx 这类查询计算所有 income 字段的总和，就很可以有造成数值溢出，所以安全起见 jdbc 会自动升为 Long 型
4：整个类型升级过程 jfinal 并未干预过，完全交由 JDBC 自动完成
此外，类似 count(x) 这样的函数也会有这样的行为
