дополнительное поле в промежуточную таблицу
Closed this issue · 4 comments
Здравствуйте. Написал сначала на форуме- попросили написать вам лично.
http://yiiframework.ru/forum/viewtopic.php?f=19&t=42879
Там же в форуме модель и таблицы описаны.
-------копия верхнего текста с форума----------------------------------
Можно ли добавлять дополнительное поле в промежуточную таблицу используя это поведение ? Что нужно прописать в Геттерах - зеттерах?
Поясню зачем .
1-я таблица это фильмы. У одного фильма может быть несколько режиссеров. Например Иванов АА, Борисов Б и Петров В , взятых из таблицы media_man.
А так же у одного фильма может быть несколько продюсеров . Тот же Иванов А.А и Петров. Они тоже взяты из таблицы media_man. Т.е в промежуточную таблицу нужен еще параметр- тип человека.
Есть вариант- сделать на каждый человека тип промежуточную таблицу- но это очень плохой вариант. Наиболее хороший- это добавить к промежуточной таблице(media_has_man) тройной ключ и поле c типом человека. Но я не уверен, что данное поведение обладает данным функционалом.
Замечу. Без дополнительного поля- поведение работает.
Вот вы написали вопросы в целых два источника, ждали ответа на форуме, ждали ответа от меня. Хотя начать надо было начать с прочтения документации вот здесь.
Спасибо, что хоть не обозвали. 1). У вас неполнота документации. Если повторишь по инструкции- не получишь результата. ( вот тут похожая тема расписана немного , но намного качественнее http://fancode.ru/post/yii2-behaviors-many-to-many). Новичёк точно не получит результата. Поэтому документация не внушает доверия. Укажу почему. а) надо указать пример таблиц б) как с этими таблицами работать в каждом варианте связей 2). Документация на английском- а разработчики и пользователи русские. 3) И самое важное- когда закрываешь в форуме тему, то правилом хорошего тона указать, каким способом я это решил. Так вот, я должен по идее указать вот этот issiues гитхаба. Но наверное придется тему закрыть , из-за того что проблема не решена.
Предисловие
К вашему сожалению я не ставил себе цели создать обучающий материал для новичков. Целью было максимально описать функционал поведения с примерами, чтобы человек прочитавший пару статей о структурах связей БД и пробовавший написать свой велосипед для обслуживания связей, хотя бы, раза 3 смог понять о чем разговор.
То, что документация не внушает доверия это странно. Она есть, она содержит все, что должно помогать разработчикам решать свои задачи. Доверять или нет - дело каждого.
На крайняк есть исходники. Они уж точно не будут врать :)
На счет ваших замечаний:
-
Если вы просите структуру таблицы, смею предположить, что вы не знаете как построить связь много ко многим. Как вы собрались пользоваться готовым решением?
Для построения связи много-ко-многим одна структура. Пожалуйста, нажмите сюда. И, пожалуйста, прочтите теоретические знания на хабре. -
Как видно – каждого варианта связей своя структура. Как с ними работать описано в офф доке Yii2. Это базовые знания, без которых вы не сможете работать с поведением. Оно так и останется черным ящиком.
-
Незнание английского... вы уж простите, в наше время это не отговорка. Как минимум по двум причинам:
- Это де-факто обязательно (хотя бы уметь читать документацию);
- Есть бесплатный средства перевода.
То есть получить перевод документации сегодня – не проблема.
-
Вы правильно делаете, что придерживаетесь правил хорошего тона. Так вот, перед созданием темы\вопроса стоит прочесть документацию. Как я понял - вы этого не сделали и это очень плохо. Не делайте так больше.
Если после изучения теории о связях в реляционных БД, после изучения документации Yii2, после изучения документации к поведению и, наконец, после изучения исходников у вас не получилось реализовать задуманное - вы имеете полное право открыть issue. Ну, это в идеальном варианте.
Ни в коем случае не хотел вас обидеть, совсем наоборот. Я выделил время, чтобы написать полный ответ на вопрос, чтобы было максимально понятно :)
На счет вашего вопроса
Мне не приходилось реализовывать такой логики, как требуется у вас.
Но вот у человека была похожая ситуация и он допилил функцию в поведении.
То есть, вы можете описать две связи в поведении и настроить у них условие выборки и значение для поля type_key, как показано в примере. Таким образом при создании записей через связи, поле тип будет заполняться само, а при получении через связь будут возвращаться только записи с этим типом.
Сразу скажу, после рефакторинга поведения эта функция не покрывалась тестами. Так что она работает с вероятностью 90%. Если протестируете ее и будут баги, напишите мне – исправим.
Благодарю за развернутый ответ. По сути могли бы только последний абзац написать.
По поводу велосипедов- уже один есть. Но он слишком кривой и не гибкий.
По поводу связи many-many и пункта 1. Я согласен , что в идеале структура промежуточной таблицы должна быть как вы описали. Но вот если бы вы работали с virtualmart ... например с табличкой virtuemart_product_categories , вы бы были несколько удивлены. Там есть автоинкремент с id , а также отдельно связующие поля к которым выставлен уникальный ключ. Ну или с bitrix, где всё в настраиваемых полях хранится ( с битриском возможно я не прав- сейчас работаю над подобной проблемой).
2, 3- согласен , но приходится работать по принципу 20-80. Иначе никак.
Итог длинной дискуссии. Нужно допиливать. Буду исправлять более лаконичный вариант- который сам нашёл.
Еще раз спасибо за ответ.