2017-09-15 10:52
@arboret jfinal 手册里面全都有, sql 管理功能用的 jfinal 模板引擎,那么模板引擎中的所有功能可以直接用于 sql 模板之中,例如你的这个 sql,用下面的结构,立即避免掉了java 代码中的 if 判断:
#for(x : cond)
#if(x.key)
#(x.key) #para(x.value)
#end
#end
以上通过一个 #if(x.key) 直接避免掉你在 java 代码中的五个 if 判断,此外,生成sql 语句的 IN(...) 这块代码,也完全可以放在模板文件之中,而 java 代码只需要准备好参数就好
生成 sql 的事情天然就该交给模板引擎来做,你现在的用法是 java 代码中做一部分,模板中做一部分,还不如直接在 java 中做完
2017-09-15 10:20
@arboret 很明显问题出在 sql 模板中的使用,但至始至终你都不出示这段代码。
永远记住:生成 "?" 问号占位的是 #para(...) 指令,而不可能与 "map中的 key" 有任何关系
目前你的解决办法很不优雅,只是在生成了错误的 sql 以后,再用 replace 再补救,与真正正确的道路相差甚远
你的 java 代码中用了很多 if 判断,显然这些判断在 sql 模板中去做会更优雅
总之:一定要先会用 jfinal 模板引擎的基本用法,然后再用好 #para,就可以解决问题
2017-09-14 11:24
@aloneJFinal 参数与上传文件本身是被包含在整个 http 封装好的流里面的,解析这个流才能得到参数与文件内容,而一旦解析,文件和参数是同时被解析的,参数存放的位置也是不确定的,或许在文件之中某个位置
2017-09-14 10:13
@听雨跳舞 有关 html 片段渲染 + ajax 的代码在 ShareController 中的 saveReply() 方法里,还有更多玩法,可以去俱乐部交流
2017-09-14 09:57
分页查询中如果使用 order by 只要是没有报异常,结果一定是正确的,当然这个结果取决于你的 sql 是否正确
paginateByFulSql 本质上只是用于复杂 order by 的情况,例如下面这种情况:
select * from xxx where ... order by ( select yy from ...) as temp
由于分页查询需要用 select count(*) from (原 sql) as temp 去计算总记录条数,而 count(...) 函数不能与 order by 同时存在,所以需要针对 select count(*) 这个查询去掉 order by 子句
问题在于 order by 可以是无限复杂的嵌套 sql,以至于要用正则彻底覆盖所有 order by 所有模式的情况会让程序性能下降一至两个数量级
因此,为了权衡性能与便利性,paginate 方法中的正则仅匹配移除最常用的 order by 模式,而 paginateByFullSql 专门针对无法彻底移除 order by 的情况而生