поддерживаю, если ты не описал, то не надо чтоб она делала. иначе неявная логика, а это всегда к багам

спасибо всем ответившим)) 🤝 значит 2 и 3 пункт в моём ответе. Буду использовать этот способ.

И второй вопрос по трудностям перевода, который я хочу прояснить для себя до конца))) Что именно мы должны передать в опции

foreignKey: 'something'

?
Так как я использую дефолтное описание моделей, то в моём случае определить это не сложно:

Post.belongsToMany(models.Tag, {through: 'post_tag', foreignKey: 'postId', as: 'labels'})

Я пишу:

foreignKey: 'postId'

Но что передавать в этой опции, когда все наименования нестандартные:
1️⃣ в промежуточной таблице название столбца с id поста такое:

post_ident

2️⃣ в определении промежуточной модели поле с id поста такое:

identPost

3️⃣ в определнии модели поста поле Primary key называется:

identification

4️⃣ в таблице поста столбец с id называется:

post_pk_id

Если я правильно понял документацию, то склоняюсь к 3️⃣ третьему варианту: это ModelName с маленькой буквы:

modelName

+ название поля Primary key

identification

Вот так:

postIdentification

Верно?

foreignKey: 'something'

Post.belongsToMany(models.Tag, {through: 'post_tag', foreignKey: 'postId', as: 'labels'})

foreignKey: 'postId'

post_ident

identPost

identification

post_pk_id

modelName

identification

postIdentification

Если делаешь связь от Постов к Тэгам
through - имя таблицы связки
foreignKey - связь Поста и таблицы связки, т.е. столбец в связке к Посту
otherKey - связь уже с Тэгом.

Как запомнить:
А имеет много Б (первая сущность имеет много вторых).
foreignKey - ключ к первой сущности. Первая главная.
otherKey - другой ключ ко второй. Вторая - другая.

Если я не наврал))

Да, вроде все так)

@ShGKme неожиданно. После прочтения документации и огромной кучи примеров я был почти в полной уверенности, что всё завязано на названии модели и полей.

Значит название столбца в промежуточной таблице. В моём примере это 1️⃣

post_ident

post_ident

Ну завязано, потому что он может сам имена придумывать.
Но всегда можно самостоятельно называть.

>Но всегда можно самостоятельно называть.

Дада. Я поэтому такой дикий пример и обрисовал. Когда всё, что можно переименовано нестандартно. Чтобы разобраться, что же точно передаётся в опцию foreignKey

Если совсем однозначно, то в foreignKey передаётся тоже самое, что передаётся в foreign в запросе на создание внешнего ключа в SQL :D

Для меня теперь это самое удобное объяснение. 👍

@ShGKme И раз уж вы упомянули otherKey, в каком случае его нужно указывать? Так как большинство примеров его не содержат. Это опять же просто явное указание в коде для упрощения последующей поддержки кода?

Я, если честно, до сегодняшнего дня бек около года не трогал, так что могу и наврать ._.
Я вот сходу не помню, для чего sourceKey...

Но вообще да, я всегда указываю все столбцы в связях. Люблю, когда всё явное.

Вспомнил, sourceKey — это когда из исходной таблицы не PK берётся, а иной столбец

А ещё и все таблицы связки тоже как модели описываю ._.

я именно про  otherKey.

А sourceKey / targetKey - это немного другое. Это когда связываемся не на primary key, а на другой столбец.

хм, я со своим минимальным опытом, склонился к другому выводу, что если связка, как сущность не имеет смысла, то описывать её не стоит.

Возможно просто упускаю, какие-то важные детали при другом подходе.

Вечер добрый, может кто то пжлст скинуть статьи о структуре проекта с использованием sequelize? Особенно интересуют модели.

ПРивет, подскажите можно ли что-бы establishmentIds был массивом? сейчас только первый элемент туда попадает. Что-то уже 2 часа в доках лажу и не могу найти...

    const res = await Organization.findAndCountAll({
      attributes: [[Organization.sequelize.col('Establishments.id'), 'EstablishmentsIds']],
      include: [{
        model: Establishment,
      }],
    });

Через .then не предлагать )