Thread.local[:current_user] 的陷阱
此问题与：访问模型中的 current_user 相关。
具体来说，我想在一个 Model.rb 中启用对 current_user 的访问。 @moif 留下了评论，指出该解决方案不是线程安全的，并且我读到使用此过程还有其他注意事项。
我的问题是这样的 - 如果我要添加：
def self.current_user
Thread.local[:current_user]
end
def self.current_user=(usr)
Thread.local[:current_user] = usr
end
到一个 Model.rb （仅轻度且不频繁使用），对我的应用程序的现实世界影响是什么以及我还需要做什么以保证其健康？
设置：Rails 1.9、Rails 3.0、Heroku、Authlogic。
This question is related to: Access current_user in model.
Specifically, I want to enable access to current_user in one Model.rb. @moif left a comment stating that the solution is not thread-safe, and I have read that there are additional caveats to using this process.
My question is this - if I were to add:
def self.current_user
Thread.local[:current_user]
end
def self.current_user=(usr)
Thread.local[:current_user] = usr
end
to one Model.rb (used only lightly and infrequently), what are the real-world implications for my app and is there anything additional I have to do to ensure its health?
Set up: Rails 1.9, Rails 3.0, Heroku, Authlogic.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不确定我是否同意你所走的道路。我同意另一篇文章，即将 current_user 传递给模型是不合适的，但我不会为此使用 Thread.local 。原因如下：
开发人员喜欢通过解决方案获取技术，并且没有什么比 Thread.local 更“接近系统”了。之前使用过 Thread.locals ，它们非常棘手，如果你没有正确使用，那么你会花费无数的时间试图找出问题，更不用说解决方案了。也很难找到能够理解 Thread.local 的复杂性并能够彻底测试代码的测试人员。事实上，我想知道有多少开发人员针对此类事情进行了可靠的 rspec 测试（或同等测试）。该解决方案的“成本”可能不值得。
我想我会看看你正在尝试做什么，看看是否有更简单的解决方案。例如，我可以立即想到两个（在您的情况下可能有效或无效）：
a）使用外键将您的历史记录表连接到您的用户表。 “属于，有很多”；或
b) 通过历史记录中的 attr_accessor 传递用户名，并在创建对象时进行设置。
I'm not sure I agree about the path you are taking. I agree with the other post that passing the current_user to the model is not appropriate but I wouldn't be using Thread.local for that. Here's why:
Developers love to get technical with solutions and there's not much more "closer to the system" you can get than a Thread.local. Having used Thread.locals before they are very tricky and if you don't get it right then you spend countless hours trying to figure out the problem let alone the solution. It also is difficult to find testers who can understand the complexities of Thread.local and be able to test the code thoroughly. In fact I would wonder how many developers put together solid rspec tests (or equivalent) for something like this. The "cost" of this solution may not be worth it.
I think I would take a look at what you are trying to do and see if there is an easier solution. For example, I can think of two off-hand (maybe would work or not in your case):
a) connect your history table to your user table with a foreign key. "belongs_to, has_many"; or
b) pass the username with attr_accessor on history and set that when creating the object.