支持一下！

👍👍👍

图片挂了

创建一个 config/initializers/lib.rb，把这个目录加载进去。

可以加一张中间表，字段是 order_id product_id package_id

赞！

这应该是ActionCable的典型应用场景吧

在after_commit中的话，可以用previous_changes来判断，哪个字段改变了。

哈哈哈，大牛你来啦！

这样的情况，我觉得并不是问题啊，正常业务如此。 你为何觉得这是一个问题呢？

我觉得 你的这个场景没有必要修改锁的机制。

只是担心，回调会不可控。

我们是按照业务类型区分文件夹的。目前有 30 个文件夹。 个人认为，如果把业务划分清楚，放文件夹下，会整齐一些，就好了 。

另外，“service 有可能会嵌套”。我目前还没有遇到过。能否举个栗子，看下呢？

“提取”。 在 service 中创建类，用来处理业务逻辑（包括计算）。

赞同八楼的观点。我们公司也有类似的业务逻辑。业务复杂了以后，save 引起回调实在难以掌控。现在我们是把逻辑统一提取到 service 中处理。整个过程很清晰，维护起来方便很多。

看下六楼。

@customer.errors.values

GO、 Python

那还有什么疑问吗？一起探讨下

method 需要 绑定在同一个对象下 == 才为 true

receiver 其实就是 Date.today

require 'date'
a = Date.today
b = Date.today

a == b # true
a.object_id == b.object_id # false

a 和 b 的值是相等的。但是不是同一个对象。

对于method_one == method_two # false，是因为 方法的接收者 不同，所以不相等。 以下是我的运行结果：

method_one.receiver.object_id # 70321140521840
method_two.receiver.object_id # 70321397845200

我的运行结果，与你不同

method_one == method_two   # false
method_two == method_two   # true

require 'thwait'

class MultipleThreadTest
  @n = 0

  def self.cal
    threads = 10000.times.map do
      Thread.start {
        @n += 1
      }
    end

    ThreadsWait.all_waits(*threads)
    @n
  end
end

p MultipleThreadTest.cal # 10000

出现 9584 的原因，其实只是部分线程没有执行完，就输出结果了。如果等待所有线程执行完成，输出结果就是 10000

深度好文！