2020-05-29 14:36
@tyroxyz 直接拼 sql 是极度危险的，有被 sql 注入的风险，像下面这样使用：
String sql = "UPDATE #(table) SET duration_min = #para(durationMin) ,update_time=#para(updateTime) ... #if ( 0 < status) #para(status) #end ";
Kv kv = Kv.by("table", 表名).set("durationMin", durationMin).....;
updateRet = Dao.templateByString(sql, kv).update();
也就是说，在 java 代码中可以使用 String 变量的形式来使用 sql 模板，极度方便
2020-05-29 11:43
jfinal 本身的行为并不是这样的，估计你们改过代码，或者 sql 写得不对
建议单步调试跟踪一下，看是哪个环境出现的问题
2020-05-29 11:40
@天晴 配置好 log4j.properties，有异常不要自己在 catch 中吃掉即可被 jfinal 做日志
2020-05-28 21:31
@himans 这个 sameSite 属性是不是一个独立的 cookie ？
还是说这是在原有 cookie 上附加的另一个值？
前者就是这样用的：
setCookie("sameSite", ...)
后者是这样用的：
setCookie("myCookie", "myValue; saveSite=...");
2020-05-28 18:20
使用如下代码：
Engine engine = RenderManager.me().getEngine();
Template template = engine.getTemplate(...);
// file 可以指向任意地方，可以使用绝对路径
String file = "/var/html/file-name.html";
template.render(..., file);
输出到任意目录下的任意文件， 极度方便
2020-05-28 16:42
@王先森 可能是数据量大，一直在执行
你可以在每次插入一批数据以后，向控制台输出提示信息，以免误判
也可以在每插入一个分页数据以后做日志
一定要想办法找到症状。 当前情况并没有抛异常，最直观的看法是程序仍然在执行，由于数据太多，外在表象是卡住了
2020-05-28 16:18
@fred 其实用 setCompressorOn('\n') 就足够好了，既保障了压缩率，又保障了压缩性能，还保障了压缩结果的可读性
2020-05-28 14:05
分页与插入，前者是查询，后者是 insert ， 信息量不够
提供更多信息量，消除不确定性，这个问题才有可能得到答案
