2017-10-23 15:10

如果使用的是 jfinal 提供的数据库操作 api,连接都是自动关闭的,无需处理

如果要自己关连接, 调用 connection.close() 关一下即可

2017-10-23 15:09

在 mysql 或者 oracle 自带的控制台中先执行这个 sql 语句,确保 sql 的性能满足需求以后,再放在代码中去使用

几乎所有的数据库层框架都只能代为将 sql 与 para 转交给数据库(更确切地说是转交给JDBC),而无法帮助优化 sql 的性能

因此,sql 的性能还需要依靠自己在数据库方面的积累,目测你的 sql in 效率低是因为 in 里面的字段没有做好索引,如果索引也做好了,数据库配置也没问题,那么看看数据量是不是非常之大,千万级的数据是没什么问题的

2017-10-23 15:06

@海哥 建议开发的时候始终提交到 dev 分支,让 master 分支始终保持可用状态

2017-10-23 15:06

@yangxianqiang 进小木学堂官方群,在 qq 里面搜索小木学堂

2017-10-23 11:31

@王小明 你的 eclipse 版本太高了吧? eclipse 高版本不知道改动了什么东东,造成了这个问题

2017-10-23 11:23

添加一个 SessionInViewInterceptor就可以了:
me.add(new SessionInViewInterceptor());

用的时候这样: #(session.value);

2017-10-23 11:22

参考一下这里: http://www.jfinal.com/feedback/402

2017-10-23 11:20

不建议 service 层依赖 web 层的东东,耦合度太高,可以在控制层先把参数准备妥当后,再传入给 service 层

如果一定要这么用,可以引入一个全局拦截器,大致如下:
public Context implements Interceptor {
static final ThreadLocal TL = new ThreadLocal();
public void intercept(Invocation inv) {
TL.set(inv.getController().getSession());
try {
inv.invoke();
} finally {
TL.remove();
}
}

public static Session getSession() {
return TL.get();
}
}

然后添加这个拦截器为全局拦截器,用的时候这样:
Context.getSession();

2017-10-23 11:15

render(view) 的 finalView 规模在 jfinal 手册中也有说明

2017-10-23 11:15

jfinal 路由规模只有四条,很简单,看一下手册肯定就清楚了,这里要说的是 render(view) 中的 view 的规则:
jfinalView = baseViewPath + viewPath + view;

1:上面的 baseViewPath 是通过 routes.setBaseViewPath(...) 配置的
2:viewPath 是通过 routes.add(controllerKey, controllerClass, viewPath) 配置的,这里注意,第三个参数 viewPath 省略掉时,则值与 controllerKey 相同
3:当 view 以 "/" 打头时,前面的 baseViewPath、viewPath 全部失效

2017-10-23 11:12

如果觉得 if 判断代码量多,可以扩展模板函数,或者通过 shared method、shared method 甚至是扩展 directive 来做这个事,都很容易,看一下手册

2017-10-23 11:11

加个 if 判断一下就可以了,例如:
#if (col1) col1 = #para(col1), #end

2017-10-23 11:10

感谢分享

jfinal 数据库操作在底层是用的 JDBC,操作模式上就是创建 sql 及其 paras,然后直接扔给了 JDBC,理论上只要是 JDBC 可以操作的, jfinal 都可以

mybatis 也是对 JDBC 的封装,相信其 selective 操作也是在 JDBC 基础上做了更一层封装

2017-10-23 11:03

access token 时效是 7200 -5 秒,微信官方要求的是 7200 秒,为了更保险 jfinal wexin 让这个时间减少了 5 秒

jfinal 通过 IAccessTokenCache 接口来存放,并且通过内部检查机制来确宝时效性

即便是中途没到 7200 秒失效的 token , jfinal weixin 也做了处理,因为每次调用 api 后,jfinal weixin 对返回值中的状态码进行了判断,只要状态码显示 token 过期,立即会重新获取

具体实现方式,可以看代码

2017-10-23 11:00

File.exists(...) 这个方法是 java sdk 中的 API,这个 jfinal 肯定是干预不到的

返回是 false,很可能就是不存在,与 main 里测试结果不同,很可能是 imgUrl 这个参数值存在细微差别