#1 楼 @fsword 早就可以 pull request 了吧...

#3 楼 @knwang 好歹查下 Wikipedia 么...

高层函数？

高阶函数!!!

可以试试改成 SSH 接口，这样写脚本就方便了

说明 JavaEye 已经从 Rails 2.x 升级到 3.x 了？

#22 楼 @luikore 我是说两个不同的问题抛相同的错...

#17 楼 @hooopo ORM 的存在就是要帮你偷懒，而不是帮他自己偷懒。

jQuery 还要搞定不同浏览器之间的差别呢，照你这么说就留给你自己搞定好了。

#18 楼 @Rei 用SELECT *可能会导致两种不同的问题，抛了个相同的错。这当然是能避免就避免的了。

一种是你的代码假设数据库有某个字段，但数据库里没有 另外一种是，你没有假定有这个字段，但你模板里写了

用SELECT *就导致两个问题，都在模板那里出错。

你把问题搞混了吧，你说的两条优点对于 ORM 来说是不成立的。

只有你自己写 SQL 语句的时候，才能体现出SELECT *打字少且在添加和修改或删除的时候不需要更改查询语句的优势。

为什么不要用SELECT *？就是为了能在执行 SQL 语句的时候就出错，而不是在模板或者其他什么地方出错。

#42 楼 @fsword 难道你没听说过有一个神奇的网站？

这个说法是有问题的吧。看 Unicode 文档，CJK 是分成好几段的

http://www.unicode.org/versions/Unicode6.0.0/ch12.pdf

0x3400 ~ 0x4DBF
0x4E00 ~ 0x9FFF
0xF900 ~ 0xFAFF
0x20000 ~ 0x2A6DF
0x2A700 ~ 0x2B73F
0x2B740 ~ 0x2B81F
0x2F800 ~ 0x2FA1F

一 - 龠 也就 4E00 ~ 9FA0 龥 也就 9FA5

#16 楼 @fsword 业务模型很难和持久化独立开的，当你需要 JOIN 的时候，你还是需要知道数据库里是哪张表的。我不觉得，所有需要 JOIN 的查询都会放在业务模型的那个 class 下面。

#15 楼 @camel 虽然验证应该在越前面越好，但像 Django 现在那样，还不如不分开的 Rails 3。我不觉得现在的strong parameters已经完全解决了类似的问题。验证相关的代码分在两个地方，代码看起来麻烦啊。

#10 楼 @knwang 看那样子就变成 data mapper 了。但我没发现你举的这个例子，在两个 pattern 里有啥区别

http://martinfowler.com/eaaCatalog/activeRecord.html http://martinfowler.com/eaaCatalog/dataMapper.html

#4 楼 @knwang 希望 Rails 能把这事搞定吧

现在 Django 分得很坑爹，搞了个半调子的 Form，弄得你用也不是不用也不是。

比如就像 GitHub 那样，每个用户的自己的仓库是不能重名的。

Django 里面你在 model 里定义unique_together = [('user', 'repository_name')]

接着，因为 user 是从 session 那里拿到的，你用 Django 自带的 ModelForm 生成 Form 的时候，会去 exclude user 这个 column。(这个是文档里提到的做法，https://docs.djangoproject.com/en/dev/topics/forms/modelforms/#using-a-subset-of-fields-on-the-form)

问题就来了，Django 的validate_unique的时候，因为 user 被 exclude 了，unique_together 里面，('user', 'repository_name')这条就直接就无视了。

据我所知 Django 到现在也没一个标准做法来处理这个问题。这个问题也不是一天两天了，是 4 年多了，这个问题一直没解决。

https://code.djangoproject.com/ticket/8795#comment:11 https://code.djangoproject.com/ticket/12028 https://code.djangoproject.com/ticket/12521 https://code.djangoproject.com/ticket/12901 https://code.djangoproject.com/ticket/13091 https://code.djangoproject.com/ticket/13249 https://code.djangoproject.com/ticket/15326

当然了，我承认在 Ruby 社区吐槽 Django 是很不好的行为。只是看到这个话题，联想到 Django 有个坑爹的问题，就顺便吐槽一下了。

#48 楼 @knwang 默认就建 Foreign Key 啊，别整个第三方的 gem，不然很多人就干脆不建 Foreign Key 了。不该迁就 MyISAM 这种功能不全的数据库引擎。

SQL 有啥功能，都要能在 ORM 里能体现出来。默认没有，很多第三方库就不会去用。差不多就相当与是把 RDBMS 当 key-value 存储用，这样，就会有人觉得 RDBMS 不好用。这也不难解释，现在有很多人会去折腾 MongoDB 这种适用范围很窄的东西。

Rails 核心开发者又不是水平不行，也不是相关部分的代码没写好，但就是能经常搞这种默认就不给你启用这种事情出来。还说啥 Rails 的默认设定是适合大多数人的，你没设对就是你水平不行，总之就是你自己的错。非要等到出事了才肯改一下默认设定。Rails 3 都号称 Secure by Default 了，还能连改 mass assignment 的默认设定都极不情愿。

不管怎么说，还是在往积极的方向发展么。模板默认会 escape 了，mass assignment 默认会过滤了。SQL 注入的问题也暴露出来了，补丁也有了。希望早一点能：默认只用数据库的客户端库来 escape，别自己 escape 了以及在参数上搞点花样，Foreign Key Constraint 默认能给我建好，除非我特别指定，别给我生成SELECT *这样的 SQL 出来。

#29 楼 @alvin2ye

irb(main):001:0> a = [[0]*8]*8
=> [[0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0]]
irb(main):002:0> a[0][0] = 1
=> 1
irb(main):003:0> a 
=> [[1, 0, 0, 0, 0, 0, 0, 0], [1, 0, 0, 0, 0, 0, 0, 0], [1, 0, 0, 0, 0, 0, 0, 0], [1, 0, 0, 0, 0, 0, 0, 0], [1, 0, 0, 0, 0, 0, 0, 0], [1, 0, 0, 0, 0, 0, 0, 0], [1, 0, 0, 0, 0, 0, 0, 0], [1, 0, 0, 0, 0, 0, 0, 0]]

#51 楼 @hooopo 这个是有点不爽，既然 Rails 都要宣扬 CoC 了，名字 Rails 自己生成一个就是啦，我才不要自己指定名字，我要 Follow 你的 Convention。比如命令长得这样就好了嘛

rails generate migration add product part_number:string

但也不至于被这个坑到，因为写错了，马上就知道了。会被坑到才算值得注意的问题。

#47 楼 @hooopo 反正这是他的想法，不是我的。我觉得他没找对该吐槽的地方，就补上了。

#45 楼 @hooopo Rails 又不会在你用 migration 加了一个 column 之后，自动把你记录各个 column 名字的变量也作相应的修改。Rails 能知道你新加了个 column，就是因为用了select *。所以，开发的时候，你不得把相关的代码给注释掉，不然加了个 column，还得去改 model 部分代码。得发布了又得把新增的 column 名补上。现在，还有谁敢拿着里面还有select *的代码去发布啊，现在都找不到多少 PHP 代码里面到处都是select *了吧。

#44 楼 @Rei

默认不建 Foreign Key 这个行为就是 Rails 早期版本的残留。

但是，甚至连 @knwang 都以为

如果你说的是 foreign key constraint，Rails 不是不会建，是选择不建。绝大多数的 app 这种选择是合适的。

而事实上，Rails 很早就不赞成不建 Foreign Key 这种做法了，在文档里肯定会告诉你该怎么建 Foreign Key 的。但是为了迁就 MyISAM，Rails 就是不建 Foreign Key，哪怕你用的是 PostgreSQL 或者 InnoDB。

#41 楼 @Rei 我就问你有多少比例的第三方 Rails 项目用了 foreigner 之类的东西，Ruby Taiwan 都是没用的吧

#35 楼 @hooopo 不总能用到版本控制啊。有时候你是按版本发布 tar 包的

#39 楼 @hooopo 小白才不敢去数据库里改吧...

#37 楼 @hooopo 我觉得他的意思是这样就不会自动生成内容了吧

#32 楼 @knwang 所以还是直接改数据库了。因为 rollback 完还要自己把那 migration 文件给删掉。还不如全都改完了 diff 一下 schema.rb，自己照着写个 migration 了。但其实这个 Rails 能搞定的，也应该由 Rails 搞定的。

就算这样也没 Foreign Key，还有其他一些 Constraint 什么的，于是就不如直接写 migration 文件，而不是用 Rails 生成了..