如果 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) 这样的函数也会有这样的行为

针对这样的升级，可以使用 getNumber(attrname).intValue() 来获取，这样就不可能出错

查询的时候，可以这样： Db.queryLong("select count(income) from account").intValue();

@JFinal ，针对这样的不确定性，如何做到统一。好像一个规律是 表ID字段会转为Long,外键ID会转成Integer。如：分类表的BaseModel中 public void setId(java.lang.Long id)
在另外一个表中作为外键就成了： public void setTypeId(java.lang.Integer typeId)

不过也有的表ID字段 也是转成 public void setId(java.lang.Integer id) {

@小飞象 除了在 sql 使用 sum count 会让 int 升级为 long 以外，还要注意以下升级的情况：
1：int(n) n > 11 的情况
2：int(11)，但是是 unsigned 无符号整型的情况
综上，你前面谈到的“表ID字段为转成Long“ 并不是本质原因

做到统一恐怕是不合理的，因为无法兼顾到数值溢出的情况，尤其是 getter、setter 返回值或参数升为 Long 的原因是确实类型就该是 Long

前面谈到setter、getter 的参数或返回值类型确实 Long 是指 int(n) n>11 以及 unsign int(11) 的情况，所以是合理的

“整个类型升级过程 jfinal 并未干预过，完全交由 JDBC 自动完成”。
@JFinal 针对这个问题，我个人觉得JFinal可以干预下。太多人遇到这个问题了...

@海哥 假定字段是 int(12)，这种情况本身就对应了 jdbc 的 Long 型，难道干预并转换？ 其实干预也不难，在生成的 BaseModel 中的 getter 方法中这样 return getNumber(attr).intValue()