Tornado Documentation
› http://www.v2ex.com/tornado/
Tornado on GitHub
› https://github.com/facebook/tornado/
Tornado Gists
› http://tornadogists.org/
这是一个创建于 4768 天前的主题，其中的信息可能已经有所发展或是发生改变。
或许这不是一段很好的代码，但是刚才实在是被模版里这样的一段表达式给震撼了：
{{ mention.event.reply_to.member.username }}
{{ mention.event.reply_to.member.username }}
 |
1
Los 2011-11-14 02:48:30 +08:00
rails 里最不缺少的就是这个
|
 |
2
ayanamist 2011-11-14 07:36:12 +08:00
已经看到无数人吐槽Storm后转到SQLAlchemy了，期待过一段时间后Livid的吐槽。
|
 |
4
huangz 2011-11-14 08:41:18 +08:00
数据量大之后Storm会出现莫名其妙的锁表问题，在pythoncn的邮件列表里有个帖子说到过。
|
 |
7
chloerei 2011-11-14 11:03:36 +08:00
补充一下，实际中做页面片段缓存或者对象缓存或者队列缓存，比数据库层面的优化更好。
|
 |
8
est 2011-11-14 11:08:42 +08:00
编程语言设计有两个方向，一钟是接近数理逻辑，一种是接近人性化。
|
|
9
huangz 2011-11-14 11:29:28 +08:00
|
|
10
ayanamist 2011-11-14 11:57:30 +08:00
|
 |
11
Livid MOD OP @ayanamist 感谢分享。
不过 March Liu 的情况是： • 他用的数据库是 PostgreSQL • 他用到了 foreign key 而目前我的项目里是 MySQL，而且没有用到 foreign key，也暂时还没有用到 transaction，所以目前一切情况还好。 当然，如果将来在我的项目中的 Storm 出现了什么奇怪问题，我会在第一时间在这里向大家分享和请教细节的。 |
 |
13
muxi 2011-11-14 13:42:15 +08:00
@chloerei 去年的今天我也是这么想的，先做起来再说。互联网业务速度增长的非常的快，就那么几个人，业务不断的还在继续增长，需求不断的新增，新招聘的人不能马上介入开发，这都是问题，虽然我不后悔当初对ORM的选择，但是从发展层面来说，我遇到了ORM这个模式本身的问题，从技术层面去重构程序需要面临的压力非常的大，首先你得保证现有业务的稳定性，还得保证能持续优化，在重构没有完成之前不能拖业务的后退，还得面临新需求的开发和迭代。在一个业务驱动的团队里，在系统没有倒掉之前，基本上你的领导都会告诉你，先做xxx，然后再去优化，等到真正倒掉的时候，开始心急火燎的要你xx天完成重构工作，而且还得保证新需求的研发。
So，我的建议是，考虑你未来18个月的需求，这不是过度优化，而是前瞻性眼光。如果你不能预估，那么就按照100倍来估计，如果你项目刚刚还是上线，还没有流量，至少要保证能承受每秒1000个请求，哪怕是现在不能，但是未来可以通过添加服务器横向扩展达到。在12个月后，重新检查你的系统，如果不能满足从那以后18个月的需求，你应该着手布置你的重构计划，如果你不能，那么至少也要邮件说明。 |
 |
14
keakon 2011-11-14 13:56:33 +08:00
都不知道这些ORM怎么处理异步，于是觉得还是自己发明轮子算了
|
 |
15
fanzeyi 2011-11-14 19:29:51 +08:00
曾经被 March Liu 批了一顿之后被推荐去用 SQLAlchemy 了..
|
 |
17
fire5 2012-09-09 21:23:29 +08:00
SQLObject
|
Select Language