为什么 HABTM 生成包含“id”的查询？柱子？
我有一个角色模型和权限模型。
角色模型：
has_and_belongs_to_many :permissions
权限模型：
has_and_belongs_to_many :roles
创建 Permissions_roles 表的迁移：
class CreatePermissionsRoles < ActiveRecord::Migration
def self.up
create_table :permissions_roles, :id => false do |t|
t.integer :permission_id
t.integer :role_id
end
end
def self.down
drop_table :permissions_roles
end
end
当我尝试向角色分配权限时，收到错误“无效的列名 'id'”。进一步检查表明，尝试执行的查询是：
INSERT INTO "permissions_roles" ("permission_id", "role_id", "id") VALUES (1, 1, 1)
它到底为什么要尝试添加具有 id 值的行？
I have a Role model and Permission model.
The Role model:
has_and_belongs_to_many :permissions
The Permission model:
has_and_belongs_to_many :roles
The migration to create the permissions_roles table:
class CreatePermissionsRoles < ActiveRecord::Migration
def self.up
create_table :permissions_roles, :id => false do |t|
t.integer :permission_id
t.integer :role_id
end
end
def self.down
drop_table :permissions_roles
end
end
When I try to assign permissions to a role, I get the error "Invalid column name 'id'." Further examination reveals that the query attempting to execute is:
INSERT INTO "permissions_roles" ("permission_id", "role_id", "id") VALUES (1, 1, 1)
Why in the world is it attempting to add a row with an id value?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
想通了。我在后端使用 Microsoft SQL。这是使用 Microsoft SQL 的众多细微差别之一。
问题是我有一个表“dbo.permissions_roles”，其中包含之前实验中的 id 字段。实际包含数据的表是“rails_sa.permissions_roles”，不包含 id（rails_sa 是我的架构和连接的用户的名称）。
由于某种我仍然无法解释的原因，模型背后的数据存储在rails_sa.permissions_roles中。但是，连接表定义来自 dbo.permissions_roles。我确信对于这种边缘情况有一个合理的解释。
Figured it out. I'm using Microsoft SQL on the back end. This has been one of the many nuances of working with Microsoft SQL.
The problem was that I had a table "dbo.permissions_roles" that included an id field from prior experimentation. The table that actually had the data in it was "rails_sa.permissions_roles" that did not include the id (rails_sa is the name of my schema and user that connects).
For some reason that I still can't explain, the data behind the models was getting stored in rails_sa.permissions_roles. But, the join table definition was coming from dbo.permissions_roles. I'm sure there is a rational explanation to this edge case.