Rails 表中没有 Primary Key 怎么办？( 暂时解决 )
暂时解决：
- 添加一个 real_id 字段，指定为 primary key
- 把原 id 字段更名成 rev_id
- 把 real_id 更名为 id
- 把 所有涉及用 id 的地方都改成 rev_id ( 血泪 )
似乎 2, 3, 4 是多余的，但是 Rails 的 convention 实在太强，如果主键不叫 id，会造成极大的不便，还是一次改对比较好。
现在还有一个问题就是 primary key 不会 auto increment . 完全不知道原因，也许是先指定后更名造成的后果，当前在 controller 中手动指定 id 加一，暂时先用着。
好吧... 接手了一个老 Rails 项目，原来的作者是个开发 IDE 的牛人，不过他从没搞过 Rails，当初也是现学现写的，一个测试都没有我就先不说了，现在碰上一个坑是这样的：
有一个 model 叫 Resource ( 嗯，你猜对了，routes.rb 里面有一行 resources :resources，不过这不是重点 )
另有一个 model 叫 ResourceRevision 是用来给 Resource 做版本控制的，就是说 Resource 的 #show 实际上显示的是某一个 ResourceRevision 的内容，每修改一次，会存成一个新的 ResourceRevision 。
然而， ResourceRevision 对应的数据表 resource_revisions 里面没有 primary key ......
resource_revisions 这个表里面有一个 id 字段和一个 resource_id 字段，resource_id 对应的是这个 ResourceRevision 从属的 Resource 的 id ，这个正常；但是 id 字段仅在一个 Resource 内部递增，下一个 Resource 又从 1 开始。不知道我说清了没有，举例子：
@revision_1 = ResourceRevision.where(resource_id: 1, id: 1) # 第 1 个 Resource 的第 1 个 ResourceRevision
@revision_2 = ResourceRevision.where(resource_id: 1, id: 2) # 第 1 个 Resource 的第 2 个 ResourceRevision
@revision_3 = ResourceRevision.where(resource_id: 2, id: 1) # 第 2 个 Resource 的第 1 个 ResourceRevision
这三个都是可以的，也就是没有一个 column 是 unique 的。
虽然已经把这两个 key 合做了 index，但是还是有些麻烦，比方说我经常会得到这种错误：ActiveRecord::UnknownPrimaryKey in ResourceRevisionsController#some_method
我也试过 composite_primary_keys 这个 gem，但是用了之后原来所有的取值都无效了，Rails 会把两个 id 合成一个数组当 id 去数据库里面取值，显然取不到，这个 gem 应该只适合特别设计的表结构。
那么现在我该怎么办呢？我在想能不能就另加一个 column，起名 unique_id 之类的，设成 primary key？如果我这样做了会有什么副作用么？有没有更好的解决方案呢？
求帮助，谢谢。
- 增加一个 column real_id，类型为 auto increment
- 把 real_id 为空的填充数据
- self.primary_key = :real_id
比方说我经常会得到这种错误：ActiveRecord::UnknownPrimaryKey in ResourceRevisionsController#some_method
原因大概是你去 update 了那条没 primary key 的记录，修改代码，改成AR.connection.execute("update xxx set xxx = xx where xx = xx and xxx = xxx;")
如果我这样做了会有什么副作用么？
没副作用，多了一个 int column 而已。其实一般中间表，我也喜欢加一个主键上去，大部分时候中间表还是需要手工维护的，从没有再到有的过程需求迁移一次，好麻烦，直接加上也不占多少空间...而且像 has many through 这种结构还可以改变查询方式。不加只能一个 join 查询，加了之后可以 has many + in 查询，分页和 top N 情况好很多。
首先增加一个 column，然后类型设成 primary_key，rails 会很牛逼的自动把已有的记录都填好空
现在就有这么个问题...hmm... 这个表里有个叫 id 的 column，但是并不 unique，这个你知道了。然后我加个 real_id 当主键，加上以后有这么个问题：@revision.id 取到的是 real_id 的值，这个 #id 方法是直接对应 primary key 而不是对应一个叫 id 的 column 的。
但是 @revision.id @revision.id= 这样的东西在项目里已经到处都是了，这一下子就全乱套了。
我于是尝试 monkey 之
def id
self.attrbutes[:id]
end
这个还能 work
def id=(a)
# 写啥呢
self.update_attributes{id: a} # 这个不 work ，还是会去更新 real_id lol
end
而且这两个 patch 其实也不能 cover 所有的 case，还有一些散布各处的不知道什么时候会跳出来咬一口，Oh，我说过一个测试都没有么......
直接用 raw sql 也许可以... 我还没有试。我对此并不反感，但是实在是要改的地方太多了，在下定决心之前，还是想找找有没有偷懒的方法 
其实仔细想一下，这个要求其实就是这样：
- 加一个 primary key column，好让这个记录能 update
- 让 @revision.id 还是指向原来的 id column ...
#9 楼 @pathbox 这种情况最直接的解决办法是替换掉 id 的调用。monkey patch 之后改变了原来接口的行为，后来维护楼主项目的人估计又得开帖骂楼主了...
再次强调一下：
monkey patch 的应用场景主要是在外部 plugin 不提供相应API接口的情况下去修复 plugin 的行为或 bug。
楼主的这种 monkey patch 的使用方式上这样的：我自己的代码有问题，不想去修改，反而去改变 AR 的接口行为。这里其实就产生了 Tech Debt，这个债要谁来还呢，应该是下一个接手项目的人...
楼主说还存在一些小问题，其实就是一个小炸弹，不修改 revision 相关的代码还好...
另，楼主一直强调没有测试，其实我觉得不写测试和没有测试就不会改代码都是病。
