real 0m9.361s user 0m9.269s sys 0m0.012s 办公机,赛扬
暂时空间足够,怕丢不怕多,大不了真多了根据数据做后台批处理。
这个没经验,估计还是要关联处理的,这种处理应该也有方案参考,不行再自己手写,
网上随便搜了下,比如http://stackoverflow.com/questions/4435826/rails-paperclip-how-to-delete-attachment
没时间深入,自己研究啦:)
顺道,controller 里面重复定义十几个类似的实例变量可以考虑重构
params[:page] 为空的考虑过了?,,,这个没关系。忽略
views 里面的变量和 controller 里面对应没错哦,去 debug @jobs变量本身看看是否 ok
这个 build,默认只 build 一个 photo,不知道有没有关系(代码太长没仔细看,也不负责任猜一个)
数据库里面只存储一个图片的路径/标识,删除数据的时候也仅仅删除数据库里面的数据。
要删除原始文件的话,需要在删除 db 数据的时候自己做关联处理。
如果富文本上传时,同时对图片做了处理,比如生成不同大小多个图,删除的时候也要考虑。(一般默认富文本框不会干这个)
重要的是,真的要删除原始图片么?真的要在删除 db 的时候同步删除图片么?一不小心删错了也要考虑。
60 左右的宜家折叠凳,有点受不了,改站着。
理论上讲人生很大一部分时间在椅子上和键盘上度过,值得投入,但是目前没有投入。
参考 sidekiq/resque 之类
如果单纯提供 api 的话,grape 没有 rails 那么厚重,运行效率会好点,也不用处理 rails 那些 api 无关的功能和坑。
如果还没有性能问题或者没有独立 api 长期维护发展需求的话,直接 rails 上做 api 我觉得也挺好。
#2 楼 @blacktulip Thx。 后端没问题,主要想偷懒前端 js,搜索没找到很方便的。
自己以前也写过(写的不好,后面前端同事重写了),就是想看看有没有更方便简洁的,也好学习下。
临时想一本,《关于来洛尼亚王国的十三个童话故事》,最早是很多年前吴虹飞博客上看到的,后来买了,觉得不错,简单。
屏大一点的好,也看显示效果,有些屏看着眼疼,整天盯着就麻烦了。
先外接键盘/显示屏吧,或者自己房子够大
性能 + 主从
另跑题一个,手上都迁移到了 postgreql(+hstore),不是 mysql 了。