2016-08-30 00:23
关键点在于在 sqlite 中使用 getColumnClassName(i) 获取不到正确的类型，而 getColumnType(i) 可以获取到正确的类型，这个行为只有在 sqlite 中是这样，在其它数据库中是正常的
目前来说，建议通过 public class MySqliteMetaBuilder extends MetaBuilder 并且覆盖掉 builderColumnMetas(...) 方法来支持 sqlite 数据库，jfinal 后续版本会考虑改进的办法
总的来说，现有的获取 meta 的方式非常稳定，只是 sqlite 中出现意外，不大可能会单独为了 sqlite 去改变以前的处理方式，一是为了稳定性。二是由于 getColumnType(i) 或许仍然不能像 getColumnClassName(i) 一样非常精准地得到相应的 java 类型
2016-08-30 00:15
@zdhl 单步调试一下，看是哪一步出的问题，在 MetaBuilder 中设置断点，查看获取 id 的那部分代码执行的情况
2016-08-29 21:04
@Kerwin 升级下驱动试试，出现这种情况表明 JDBC 无法正确反射出正确的类型，记得搞定后发篇分享出来，感谢支持 jfinal 社区
2016-08-29 17:10
是否设置了方言： generator.setDialect(new Sqlite3Dialect())
jfinal 生成 base model 时会通过反射获取的字段类型，完全依靠的 JDBC 得到的值，理论上来说是不会出错的
此外，是所有的 integer 都识别为了 String，还是少数情况？
2016-08-29 12:25
@nbjgl @飞羽 我个人对缓存的使用的基本路子是：
1：先不使用缓存，完全无视缓存，用数据库保存数据，并实现功能
2：在需要缓存加速的地方，引入缓存
3：缓存只在 service 层中引入，service 层以外完全不知道缓存的存在
这样做的好处是：
1：以数据库为核心，缓存只在适当的地方做辅助，数据可以持久化，避免了缓存断电丢失的情况。数据库存放数据更加结构化，便于管理，而缓存结构化差，不易于管理
2：缓存只在业务层中，业务知道自己如何管理缓存，例如某个业务的 getList(...) 方法使用了缓存，那么在这个业务的 delete()、update() 方法就可以精准地更新缓存，缓存管理统一在了当前的业务层之中，不会散布到各处，易于管理，不易出错
3：缓存对于业务的调用者完全透明
2016-08-29 12:15
referMe 这个字段用于存放 @提到我 数量，message 用于马上要做的私信功能，你还可继续添加字段用于存放其它类型的数据。
1：每次有 referMe 到来时让这个字段加1
2：用户访问网站的时候会去缓存取这个 remind model，如果没有则去数据库读，如3：果字段值大于 0 则显示 tips 提示框
4：当用户点击了 tips 提示框的链接，或者进入过 /my/referMe 这个 action 将 message.referMe 的值置为 0即可
2016-08-29 12:11
@nbjgl 没那么麻烦，我直接贴出 remind 表的设计
CREATE TABLE `remind` (
`accountId` int(11) NOT NULL COMMENT '用户账号id，必须手动指定，不自增',
`referMe` int(11) NOT NULL DEFAULT '0' COMMENT '提到我的消息条数',
`message` int(11) NOT NULL DEFAULT '0' COMMENT '私信条数，未来考虑加粉丝增加个数',
PRIMARY KEY (`accountId`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
2016-08-29 09:46
就是这个方向，注意三点：
1：原来的 classDefineTemplate 中是 extends Model，改成 extends CommonModel
2：让 CommonModel 继承 Model
3：使用生成器时注入：generator.setBaseModelGenerator(new ResetBaseModelGenerator())
