Sequelize多对多关联中belongsToMany错误解析与最佳实践

1. 理解Sequelize多对多关联

在数据库设计中，多对多（Many-to-Many）关系是一种常见的关联类型，例如角色（Roles）与权限（Accesses）之间的关系，一个角色可以拥有多个权限，一个权限也可以被多个角色拥有。在Sequelize中，这种关系通常通过一个“中间表”（Junction Table或Through Table）来实现。

例如，RoleList 模型和 AccessList 模型通过 RolePermission 中间表进行关联。

• RoleList (角色列表)
• AccessList (权限列表)
• RolePermission (角色权限关联表)

Sequelize提供了belongsToMany方法来定义这种关联。当定义 RoleList.belongsToMany(AccessList, { through: RolePermission, foreignKey: 'role_name' }) 时，Sequelize会尝试根据配置找到关联模型的正确字段，特别是目标模型（AccessList）的主键。反之亦然，当定义 AccessList.belongsToMany(RoleList, { through: RolePermission, foreignKey: 'access_id' }) 时，Sequelize会查找目标模型（RoleList）的主键。

2. 错误分析：TypeError: Cannot read property 'field' of undefined

在Sequelize中，当尝试建立belongsToMany关联时，如果遇到TypeError: Cannot read property 'field' of undefined at new BelongsToMany ... this.target.rawAttributes[this.targetKey].field这样的错误，这通常意味着Sequelize无法正确识别目标模型（target）的主键（targetKey）属性。

具体来说，在AccessList.belongsToMany(models.RoleList, ...)这条关联定义中，RoleList是目标模型。Sequelize会尝试访问RoleList.rawAttributes[RoleList的主键].field来确定关联字段。如果RoleList模型的主键没有被正确定义，或者Sequelize无法通过targetKey找到对应的属性定义，就会导致this.target.rawAttributes[this.targetKey]为undefined，进而尝试访问undefined的field属性时抛出TypeError。

根据提供的代码和错误信息，导致此问题的主要原因有两点：

2.1 主键定义不明确

在RoleList模型的定义中，name字段在迁移文件中被定义为主键：

// role-list-migration.js
await queryInterface.createTable('RoleLists', {
  name: {
    allowNull: false,
    primaryKey: true, // 这里明确了name是主键
    type: Sequelize.STRING
  },
  // ...
});

然而，在RoleList模型文件中，name字段在init方法中没有明确声明为primaryKey: true：

// role-model.js (原始错误代码)
RoleList.init({
  name: DataTypes.STRING, // 缺少 primaryKey: true
}, {
  sequelize,
  modelName: 'RoleList',
  tableName: 'RoleLists',
});

Sequelize在处理模型关联时，会依赖模型定义中声明的主键信息。如果模型定义与迁移文件中的主键不一致，或者主键未明确指定，Sequelize就无法正确识别目标模型的主键字段，从而导致上述TypeError。

喵记多

喵记多 - 自带助理的 AI 笔记

27

查看详情

修正方法： 在RoleList模型的init方法中，明确将name字段定义为主键。

// role-model.js (修正后)
'use strict';
const {
  Model
} = require('sequelize');
module.exports = (sequelize, DataTypes) => {
  class RoleList extends Model {
    static associate(models) {      
      RoleList.belongsToMany(models.AccessList, {
        through: models.RolePermission,
        foreignKey: 'role_name',
        otherKey: 'access_id' // 明确otherKey，提高可读性
      });   
    }
  }
  RoleList.init({
    name: {
        allowNull: false,
        primaryKey: true, // 关键修正：明确name是主键
        type: DataTypes.STRING,
   }
  }, {
    sequelize,
    modelName: 'RoleList',
    tableName: 'RoleLists',
  });
  // RoleList.removeAttribute('id'); // 此行应移除，见下文解释
  return RoleList;
};

2.2 不恰当使用removeAttribute('id')

在RoleList和RolePermission模型中都使用了removeAttribute('id')。

• RoleList模型中的removeAttribute('id'): 由于RoleList的迁移文件明确将name定义为主键，并且没有id字段，因此在模型中调用removeAttribute('id')是多余的，但并非直接导致TypeError的原因。然而，如果name没有被正确声明为主键，同时又移除了id（即使id不存在），可能会导致Sequelize在内部处理时找不到任何明确的主键，从而引发其他问题。最佳实践是，如果模型没有id字段且有明确的自定义主键，则无需调用此方法。

• RolePermission模型中的removeAttribute('id'): RolePermission的迁移文件明确定义了id作为主键：

  // role-permissions-migrations.js
  await queryInterface.createTable('RolePermissions', {
    id: {
      allowNull: false,
      autoIncrement: true,
      primaryKey: true,
      type: Sequelize.INTEGER
    },
    // ...
  });

  登录后复制

  但RolePermission模型却调用了removeAttribute('id')：

  // role-permission-model.js (原始错误代码)
  RolePermission.init({
    // ...
  }, {
    sequelize,
    modelName: 'RolePermission',
    tableName: 'RolePermissions',
  });
  RolePermission.removeAttribute('id'); // 错误：移除了实际存在的主键

  登录后复制

  这导致模型层面上RolePermission失去了其主键，这对于Sequelize管理中间表至关重要。中间表作为关联的一部分，其自身也需要一个稳定的主键来确保数据完整性和Sequelize的内部操作。

修正方法： 移除RoleList和RolePermission模型中的removeAttribute('id')调用。

// role-permission-model.js (修正后)
'use strict';
const {
  Model
} = require('sequelize');
module.exports = (sequelize, DataTypes) => {
  class RolePermission extends Model {
    static associate(models) {
      // RolePermission作为through模型，通常不需要定义自己的associate方法
      // 如果需要，这里可以定义与RoleList和AccessList的belongsTo关联
    }
  }
  RolePermission.init({
    role_name: {
        type: DataTypes.STRING,
        onDelete: 'CASCADE',
        references: {
          model: "RoleLists",
          key: "name",
          as: 'role_name'
        }
      },
      access_id: {
        type: DataTypes.INTEGER,
        onDelete: 'CASCADE',
        references: {
          model: "AccessLists",
          key: "id"
        }
      },
  }, {
    sequelize,
    modelName: 'RolePermission',
    tableName: 'RolePermissions',
  });
  // RolePermission.removeAttribute('id'); // 关键修正：移除此行，保留id作为主键
  return RolePermission;
};

3. 关联定义最佳实践

除了上述修正，确保belongsToMany关联的foreignKey和otherKey（可选，但推荐明确）参数与中间表中的外键字段名保持一致。

// role-model.js (完整修正后的associate方法)
class RoleList extends Model {
  static associate(models) {      
    RoleList.belongsToMany(models.AccessList, {
      through: models.RolePermission,
      foreignKey: 'role_name', // RoleList在RolePermission中的外键
      otherKey: 'access_id'   // AccessList在RolePermission中的外键
    });   
  }
}

// permission-model.js (完整修正后的associate方法)
class AccessList extends Model {
  static associate(models) {
    AccessList.belongsToMany(models.RoleList, {
      through: models.RolePermission,
      foreignKey: 'access_id', // AccessList在RolePermission中的外键
      otherKey: 'role_name'   // RoleList在RolePermission中的外键
    });
  }
}

注意：

• foreignKey：指定当前模型（调用belongsToMany的模型）在中间表中的外键。
• otherKey：指定目标模型（belongsToMany的第一个参数）在中间表中的外键。

4. 总结与注意事项

解决Sequelize belongsToMany关联中的TypeError: Cannot read property 'field' of undefined错误，关键在于：

1. 确保模型主键定义与迁移文件一致：如果模型有自定义主键（非id），务必在Model.init()中通过primaryKey: true明确声明该字段为主键。
2. 谨慎使用removeAttribute('id')：
   • 对于拥有自定义主键且迁移文件中没有id字段的模型，removeAttribute('id')是多余的，可以移除。
   • 对于迁移文件定义了id作为主键的模型（尤其是中间表），绝不能在模型中调用removeAttribute('id')，否则会导致模型失去主键，引发关联问题。
3. 明确foreignKey和otherKey：在belongsToMany关联中，清晰地指定foreignKey和otherKey可以提高代码的可读性，并帮助Sequelize正确建立关联。

遵循这些最佳实践，可以有效避免Sequelize多对多关联中常见的配置问题，确保应用的稳定运行。在遇到类似错误时，应首先检查涉及关联的各个模型的主键定义是否正确，以及是否存在不当的removeAttribute('id')调用。

以上就是Sequelize多对多关联中belongsToMany错误解析与最佳实践的详细内容，更多请关注php中文网其它相关文章！