Rails 远程数据库的委托模式？
我正在开发一个需要基于角色的权限的 Rails 应用程序（我们将其称为“隐藏”应用程序），但该应用程序不会处理用户身份验证。主应用程序设置加密的 cookie，隐藏应用程序使用它作为身份验证的证据。
隐藏应用程序需要实现多种角色；管理员、项目经理、编辑等。我使用 授权插件 来创建roles 表和 users_roles 表，并使用 users_roles 在用户表和角色表之间使用 has_many 关系桌子。到目前为止所有漂亮的香草东西。
挑战在于主应用程序已经有一个 users 表和一个 users_roles 表。我有一个使用 Main 应用程序数据库（创建自定义连接）的 Main::User 模型，但是当尝试通过创建角色来利用授权基础结构时，操作失败，因为 ActiveRecord 正在使用来自 Main::User 的连接信息表，它尝试更新主应用程序中的 users_roles 表（这是不允许的）。我什至尝试删除 habtm 规范并使用 has_many 宏和 :through 选项来指定联接表，但 ActiveRecord 仍然使用 Main 数据库，因为连接是通过 Main::User 模型建立的。
下一步是实现 Rails Recipe 15“连接到多个数据库”，但我缺少的部分是如何使我的本地参考模型 UsersReference 自动引用主应用程序的 users 表。该配方提到，“当然，这个解决方案需要在product_references表中创建必要的行，以匹配我们在备用数据库中拥有的任何产品。这可以批量完成 或在运行时自动进行。”我宁愿不必维护双副本 - 有超过 425,000 个用户，并且他们的状态一直在变化，因此进行批量更新的想法不是很令人满意。
理想情况下，我希望配方中的 UsersReference 模型充当 users 表的委托，我想这将涉及在运行时自动从 users 表中获取行，如配方中所述。有没有人有这样做或类似的事情的经验，我非常感谢你的想法。
I am working on a Rails application that requires roles-based permissions (let's call it the "Hidden" application), but the application will not be handling user authentication. The Main application sets an encrypted cookie and the Hidden application uses that as evidence of authentication.
The Hidden application needs to implement a variety of roles; administrator, project manager, editor, etc. I am using an authorization plug in that creates a roles table and a users_roles table and uses has_many relationships between the user table and the roles table using a users_roles table. All pretty vanilla stuff so far.
The challenge is that the Main application already has a users table and a users_roles table. I have a Main::User model that uses the Main application database (creating a custom connection), but when trying to leverage the authorization infrastructure by creating a role, the operation fails because ActiveRecord is using the connection information from the Main::User table, which tries to update the users_roles tables in the Main application (which is not permitted). I've even tried removing the habtm specification and use the has_many macro with the :through option to specify the join table, but ActiveRecord still uses the Main database because the connection gets set up through the Main::User model.
The next step was to implement Rails Recipe 15 "Connecting to Multiple Database", but the part I'm missing is how to make my local reference model, UsersReference, automatically reference the users table of the Main application. The recipe mentions, "This solution would, of course, require the necessary rows to be created in the product_references table to match any products we have in the alternate database. This could be done either in batch
or automatically at runtime." I'd rather not have to maintain dual copies -- there are over 425,000 users and their status change all the time, so the idea of doing batch updates isn't very palatable.
Ideally, I would like the UsersReference model from the Recipe to act as a delegate to the users table. I imagine this would involve getting the rows from the users table automatically at runtime, as described in the recipe. Does any one have experience in doing this or something like this? I'd greatly appreciate your thoughts.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
到目前为止，我已经通过删除 UsersReference 模型并在隐藏应用程序中创建 Users 模型解决了这个问题。我定义了 User.find_user，它检查用户 ID 是否在本地表中。如果不是 User 则从 Main::User 模型中获取它并将其保存在本地。隐藏用户模型是用于授权的模型，它满足授权插件的需求。我最不想做的就是隐藏 User.find 方法，这样它就不会被意外调用，但是创建 self.find(*arg) 并将其设置为 protected 或 private 不起作用 - User.find仍然可以调用。
I've solved it so far by removing the UsersReference model, and creating a Users model in the Hidden app. I've defined User.find_user, which checks to see if the user ID is in the local table. If it isn't User fetches it from the Main::User model and saves it locally. The Hidden User model is the one used for authorization, which fulfills the needs of the authorization plugin. The last thing I'd like is to hide the User.find method so that it can't be called accidentally, but creating a self.find(*arg) and making that protected or private didn't work -- User.find was still callable.