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) 这样的函数也会有这样的行为
2016-08-31 21:50
配置问题，JDK 与 JRE 是不同的，前者有 javac 这个编译程序，后者没有，而 jsp 文件是需要 javac 动态编译成 classes 的，所以改一下 eclipse、IDEA 中的配置就可以
2016-08-31 19:00
感谢你的分享，内容可以随时修改的，所以提交后不用担心， ctrl + 回车就可以提交是为了让用户体验更好，回贴的功能也是可以 ctrl + 回车快捷回复的。
虽然问题是解决了，但是为啥会是 byte 类型呢？ 是不是 tinyint(1) 引发的，此外，用 count(*) 有没有问题？
2016-08-31 17:57
具体的 sql 是怎么样的？ 相应的数据表字段如果是 tinyint(1) 建议改为 tinyint(2)，因为 jdbc 会将 tinyint(1) 自动转换为 boolean 类型，但也不会是 Byte 型
2016-08-31 17:39
url 组成： controllerKey + methodName，这个 controllerKey 是指 me.add(controllerKey, ....) 配置的第一个参数
2016-08-31 17:38
给一个记忆方法：
1：controllerKey 找到 Controller 类
2：controllerKey 后面的 methodName 找到 Controller 类中的 methodName()
3：当访问的 url 中省去 methodName 时，找到 Controller 类中的 index() 方法
