感谢建议

这样也极好的

我之前想到的是 如果请求 ServiceA 的 /api/orders 接口

ServiceA.api.orders.index name: 'ruby'
ServiceA.api.orders.create name: 'rails', version: '5.0.1'

.get 这种主要是用来对付对面服务不是严格 Restful 的情况

rua!

然而能做的事情比较有限 让它承担的东西太多的话，可维护性又要大打折扣

哈哈哈😄

我想到一个 gem active_type

你的包打出来多大啊，你打入了太多不必要的东西了，编译依赖在编译完是需要移除的，而且得在同一层中

我们也是 而且是在生产环境的 base 镜像中就写入了

#2 楼 @xiaoping_rubyist 呃，这也算复杂啊 那么你一定没写过 php

另外还有一个很腻害的，就是传说中的宇宙飞船 <=>

再另外，一说到 === 就提 case…when 其实埋没了它的实用价值，我一直用它来做正则检测，感觉比 =~ 用起来舒服

@huhongda

是不是你 13 这条记录的 parent 指向了自己

尝试用一下自连接来解决这类问题吧 http://guides.ruby-china.org/association_basics.html#%E8%87%AA%E8%BF%9E%E6%8E%A5

诶 我又回来了 接 #25 楼贴的图 那个就是 model 生成关联属性的方法，它指明了 as 这种关联的 type 是 owner.class.base_class.name owner 是当前的 AR 记录，可以看到它取的 base_class 的名称

Car.first.association('prices').owner.class.base_class.name #=> "Car"
Bicycle.first.association('prices').owner.class.base_class.name #=> "Car"

当然，这里只是取值的时候，如果要强行篡改，可以在它初始化之后修改它的接收器 attributes，但是这是个内部变量，我没有找到可以用来修改的 setter，也就怪不得那个歪果仁提了个 PR 来处理这个问题

另外我上面也提到了，这是一种设计的行为，并非 bug，即使抛开类继承这种限制。而且我同意 #32 的看法，这里应该是不影响使用的吧，只是数据上面 "prices"."priceable_type" 是 Car, Bicycle 的数据也是记录在 cars 表中，这样的数据库设计是健壮的，脱离 rails 也是没问题的

如果真的是 "prices"."priceable_type" 存的 bicycle, 但是根本没有 bicycles 这张表，Bicycle 只出现在 cars 表中有个叫 type 的字段上。。。。。当这个数据库脱离了你的代码，换一个系统来驱动时，估计你同事会骂死你，哈哈哈~

呃 我结合 #20963 那个 PR 看了下 Rails 的实现，我上面关于 类变量 的猜测应该是不对的，这里不是类变量导致的

按这个来看，Rails 直接指定了使用 base_class.name ，看来是有意为之啊

其实我不建议 Bicycle < Car 除非从对象自身来说他们就是继承关系，比如 Polo < Car

如果你只是想实现代码复用，可以尝试用一下 Model 的 concerns，然后在 Bicycle 和 Car 中去 include。模型间的关系，老老实实在每个模型里声明就好了。

其实我已经在第三条回复里写出答案了，但是当时在车上，没法验证，我又给删了，23333 ~~~

这个行为和 Rails 是没什么关系的，先看个栗子：

class A 
  @@n = self.name
  def self.my_name
    @@n
  end
end

class B < A
  def self.b_name
    @@n
  end
end

puts A.my_name #=> "A"
puts B.my_name #=> "A"
puts B.b_name #=> "A"

类继承的时候，是会连着类变量一起继承的

Car 这个类在初始化的时候，会写入一个类变量 @@priceable_type = car Bicycle 在继承的时候并不会主动去改写这个变量

因为这是 ruby 本身的行为，所以 Rails 开发组认为这种行为就是符合预期的行为。如果真的按楼主设想的那种行为去修改 rails 的话，仔细想想对开发者反而会成为一种负担，因为模型间关系的可读性会变得很差，需要跳多个文件才能理清楚关联关系，在一个稍微复杂一点的系统里这简直就是个噩梦。

看了几遍才明白你想表达什么 代码贴错了吧

前两天我也刚纠结过这个问题，看心情吧 😄

插件也是 js，也许可以通过在页面里预载一点有针对的 js 把插件的功能破坏掉

你一定要标示自己穿的是大号么，哈哈哈

看完之后马上去检查自己写的 rake 果然是 CSV.parse

#10 楼 我觉得这样的方案可能更好

resources :orders do
  resources :reviews, shallow: true
end

resources :products do
  resources :reviews, shallow: true
end

对应的文件是

|- reviews_controller.rb
|- orders_controller.rb
\- products_controller.rb

浅层嵌套是一个伟大的设计，很大程度避免了深层嵌套导致的路由复杂，又可以代码复用

速递易 ～

帖子已经转给我们头了

其实我觉得你这样的情况 使用浅层嵌套会更合适

#5 楼 @mizuhashi 如果你参加了 rubyconf 2016 你肯定就不会再认为他们是同一个东西了

resource 和 model 是不应该划等号的 比如两个 model 间的关系就可以是一个单独的 resource 但我们很少把它做成一个单独的 model，毕竟 rails 设计上就是通过关联来约定 model 间关系的

一个标准的 controller 不应该包含 7 个标准动作以外的任何 public 方法

ruby-china 回复编辑器改规则了么？ 换行不会被转义成 <br> 了（不知道我是不是个例）

虽然这样确实更符合 Mardown 的规则，但是有点不习惯了

#13 楼 @ztt1991 #12 的文档中有啊

1.2 什么时候做数据验证？这一节

下列方法会做数据验证，如果验证失败就不会把对象存入数据库： create create! save save! update update! 爆炸方法（例如 save!）会在验证失败后抛出异常。验证失败后，非爆炸方法不会抛出异常，save 和 update 返回 false，create 返回对象本身。

#11 楼 @xiaobai2 默认情况下，每次调用 valid? 方法时都会执行自定义的验证方法， :create, :update 都会调用

http://guides.ruby-china.org/active_record_validations.html#%E8%87%AA%E5%AE%9A%E4%B9%89%E9%AA%8C%E8%AF%81%E4%BD%BF%E7%94%A8%E7%9A%84%E6%96%B9%E6%B3%95

从你的截图看，COMMIT 成功的那次是走了你的 validate 的，而且通过了

然后又立马起了一个事务，又执行你的 validate，没有通过，于是事务回滚了，这个时候就会抛出你收到的报错

所以我推断你的 save 被发起了两次，看上去就出现了你所说的，数据都存了，然后才 validate 的现象

如果你只想在插入数据时验证应该用 validate :only_three_by_day, on: :create 否则 update 的时候，也会触发验证