Bitrix D7 ORM: как организвать отношение многие-ко-многим (ManyToMany/N:M)?

Question

[ragnar_ok]

Следуя курсу, создал сущность DeveloperTable. Нужно связать эту сущность отношением многие-ко-многим (ManyToMany) с сущностью RegionTable (такая же по структуре сущность):

use Bitrix\Main\ORM\Data\DataManager;
use Bitrix\Main\ORM\Fields;

class DeveloperTable extends DataManager
{
    public static function getTableName()
    {
        return 'developer';
    }

    public static function getMap()
    {
        return [
            (new Fields\Relations\ManyToMany('REGION', RegionTable::class))->configureTableName('developer_region'),
            new Fields\IntegerField('ID', [
                'primary' => true,
                'autocomplete' => true,
            ]),
            new Fields\TextField('NAME'),
        ];
    }
}

Теперь вызываю:

DeveloperTable::getEntity()->compileDbTableStructureDump()

Выводит:

array(1) {
  [0]=>
  string(100) "CREATE TABLE `developer` (`ID` int NOT NULL AUTO_INCREMENT, `NAME` text NOT NULL, PRIMARY KEY(`ID`))"
}

Естественно createDbTable() создает только одну таблицу. Как создать developer_region для связи?

Comments

[Евгений]

Вторая таблица тоже должна быть описана и создана как и первая.
При использовании полей будет создана 3я таблица с данными связи элементов обоих таблиц

[ragnar_ok]

Евгений, конечно вторая таблица уже создана. Я же указал в вопросе: RegionTable (такая же по структуре сущность).
При использовании полей будет создана 3я таблица - можно, пожалуйста, подробнее? Что значит использование полей?

[Евгений]

При связи M:N в отличии от других видов связи, значения хранятся в 3й таблице, а не в полях уже существующих
Даже в документации этот момент частично отражен. Там написано что автоматом создается виртуальная сущность этой таблицы и дан пример как это выглядит в базе.
При добавлении данных в ваши таблицы и указании связи между элементами, она будет создана автоматически и в нее сохраниться информация о связи между ними

[ragnar_ok]

Евгений, то, что при такой связи fk хранятся в 3 таблице - это понятно. Поэтому я и не понял по какой причине вызов createDbTable не создал 3 таблицу. Теперь понял. Спасибо! То есть вообще не надо использовать createDbTable? Нужно сразу использовать методы CRUD?

[Евгений]

Да все верно, как иначе если сущность 3й таблицы виртуальная создается каждый раз во время работы.

[ragnar_ok]

Евгений, но такой подход:

$dev = DeveloperTable::getByPrimary(1)
    ->fetchObject();
$reg = RegionTable::getByPrimary(1)
    ->fetchObject();
$dev->addToRegion($reg);
$dev->save();

Выводит:
Mysql query error: (1146) Table 'schema.developer_region' doesn't exist (400)
Значит все-таки developer_region создать нужно? Используя фреймворк можно?

[Евгений]

Мдя, провел пару экспериментов, не создается таблица автоматом, даже на последней версии....
Самому стало интересно ковыряюсь в исходниках этой "поделки".

[ragnar_ok]

Евгений, не понимаю почему в документации об этом ни слова. Миграций не требую, но хотя бы упомяните в документации о том, что таблицу нужно создавать запросом, минуя средства фреймворка.

Answer 1

[ragnar_ok]

Нужно в ручную запрашивать линкующую таблицу. Средствами фреймворка на сегодня это не предусмотрено.

CREATE TABLE `developer_region` (
  `developer_id` int(11) NOT NULL,
  `region_id` int(11) NOT NULL,
  PRIMARY KEY (`developer_id`,`region_id`),
  CONSTRAINT `FK_developer` FOREIGN KEY (`region_id`) REFERENCES `region` (`id`),
  CONSTRAINT `FK_region` FOREIGN KEY (`developer_id`) REFERENCES `developer` (`id`)
);

Либо описывать сущность линкующей таблицы и использовать createDbTable()