2016-08-14 14:24

@cyx3954 @小木学堂 貌似用过这种方式,建议问下他

2016-08-14 14:15

问题很明显,真正上传的图片仍然是原文件而并非压缩以后的文件。对于 getFile(...) 来说,不知道前端做了什么处理,只会很机械化地接收前端传过来的数据

这个与是不是隐藏的 input 都没有关系,只需非常可靠地确保上传的是压缩以后的文件即可

2016-08-13 21:08

jfinal 并未提供 quartz 插件,jfinal 2.3 会添加一个 cron4j 插件,需要提前使用的可以看看这篇分享:http://www.jfinal.com/share/37

2016-08-13 15:15

@sdfsf 首先要找个工具能将 excel 中的数据读出来,记得这个工具叫 PIO 还是 POI

2016-08-13 09:09

@楚康生 这个不丢人,用户期许 jfinal ide 搞定 web.xml 配置是合理的,建议 @小木学堂 加上这个功能

2016-08-12 17:04

Db.update(Sqls.get(key)); 即可打完收工

2016-08-12 15:50

单表信息在千万条记录以下都不算大,切勿提前优化

2016-08-12 14:23

@sdfsf 通过 getFile 获取到 excel 文件,然后找一下能读取 exclue 的工具包即可

2016-08-12 14:23

简单来说我是建议在性能压力大的时候采用数据库集群,使用读写分离的方式提升效率,分库分表相对来说比较麻烦。读写分离是对开发者透明的,可以使用中间件或者配置 mysql 的方式自动化实现读写分离。

回到你这的问题:
1:这种思路是可以的,但关键在于对开发者来说要是透明的,不需要开发者去处理不同数据库之间的差异,例如,你可以通过扩展 MyDbPro extends DbPro,将 MyDbPro 注入到 Db 中替换原来的DbPro 对象,在这个 MyDbPro 中使用一个 threadlocal 来自动化去判断数据库是哪个,然后自动化 use(...) 到不同的数据库上去。对于 Model 来说,你可以通过实现一个 MyBaseModel 继承原来的 BaseModel 实现数据源自动切换。或者是针对不同的数据源映射到不同的 Model 上去最好。

2:建议就是我刚刚讲的,一是尽可能使用读写分离集群方式。二是可以将大系统拆分成小型服务,让这些个小型服务都使用独立的数据库,再通过 jfinal 提供 http api 将服务连接起来。如果一定要分库分表,建议要建立一套自动化封装,让开发者不用关心分库分表的事情

2016-08-12 12:38

登录功能以后会做成 https 传输,现在很多功能还需要做所以顾不上 https。对于 jfinal 社区来说,撞库是不可能的,因为社区密码保存的是: sha512(32个随机字符salt + 密码),即便是被人拿到数据库也是安全的,彩虹表和密码字典破解攻击都是无效的。

感谢反馈哈 ^_^

2016-08-12 12:21

@FS心情 在个人空间还有一点点功能完善好以后,会立即出一个官方 API 频道,文档详细到方法的参数代表的意思,使用案例代码,多多关注社区动态

2016-08-12 12:16

@海哥 有地址的可以加,没有地址的就可以不加,例如,有些反馈可能是 QQ 群里看到的很有价值的只言片语。我自己还有个经验,当看到反馈做备忘的同时,如果当时针对该反馈就有了一些idea,也会同时记录下来,对于后面做改进的时候有益,因为灵感、idea 这种东西稍纵即逝

2016-08-12 12:03

@海哥 建议将一些有价值的反馈,以列表的形式放在一个文本文件里面,可以带上链接地址关联到社区文章,在以后处理的时候可以快速进入状态。jfinal 将所有的有价值的反馈都做了备忘,升级新版本的时候会统一处理