2016-09-30 14:02

@老八 刚才试了一下的确不会报错了,但是个人还是建议对于这种查询对象的需求,最好还是通过sql确保只能查出一条数据来,否则有可能出现这种情况,你先查询出了1000条数据(甚至更多),然后findFirst方法帮你取出第一条。有点得不偿失。

2016-09-30 12:07

@JFinal 我打算捐助100块钱,每次一分。好吧,你肯定用缓存了。只是我在想,如果数据达到上万条,页面会变成什么样。

2016-09-30 12:01

@JFinal 这样配置的话只能访问静态资源吧。我现在都是这么写proxy_pass http://127.0.0.1:8080/;

2016-09-30 11:33

@老八 我在之前使用中这么写都会报错的,而且这个错让我刻骨铭心。但是刚才看了下源码的确是取第一条。

2016-09-30 09:48

聚合的接口都是收费的,虽然费用还能接受。有很多免费查询归属地的接口,比如:http://tcc.taobao.com/cc/json/mobile_tel_segment.htm?tel=手机号

2016-09-30 09:38

@JFinal 波总,你说的第三种情况,如何绕过tomcat直接访问WEB-INF下的资源,这样:http://localhost/WEB-INF/web.xml?我试了一下会报404啊。

2016-09-30 09:10

@JFinal 话说波总,你那个捐助页面就已经很长了,就不考虑分分页,呵呵。

2016-09-30 09:08

@老八 话说你这么写Db.findFirst("select * from table")不会报错吗?你查询的是一个对象,但是你的语句明显是查一个list

2016-09-29 15:08

最好说的详细一些,比如贴一下你的关键代码。

2016-09-29 10:10

@clatt List files = this.getFiles(path);这样就获取到一个上传文件集合了。你再遍历着处理就行了

2016-09-26 19:36

jFinal的ActiveRecord确实很方便,能很容易的嵌入所有现有系统,我个人尤其喜欢对多数据源的处理和使用上。

2016-09-23 17:50

有的,可以使用Db.query(sql),Db.find(sql)之类的操作。

2016-09-23 17:37

看了一下源代码,感觉确实有这种风险,不管你以后的验证码如何变化,我只要记住你第一次或者其中任何一次的cookie值以及对应的明文验证码,我在模拟请求前,每次都先重置你的cookie值换成其中一次的,然后固定发送对应的明文验证码即可。因为你前台的cookie已经被我改了,所以你真正的验证码已经没什么用了。这种验证思路的不足之处在于,用于验证的关键数据cookie值可以伪造。各位大神,不知道我说的对不对。

2016-09-18 20:04

很长的sql写在java文件里确实不舒服,也不方便维护。我现在使用的就是利用beetl模板从xml文件里读取sql,但是写起来确实没用mybatis方便。