Взаємозв’язки між сутностями (застарілий варіант)
Створення, оновлення, видалення та вибірка даних – цілком вагомий функціонал, достатній для організації роботи з незв'язаними даними. Однак, веб-проекти найчастіше мають на увазі взаємозв'язки між сутностями, тому передбачені різні види зв'язування сутностей:
Відносини 1:1
Описати таке ставлення можна так:
| Параметри | Опис |
| Перший | задається ім'я поля |
| Другий | назва сутності-партнера, з яким формується відношення |
| Третій | описує, за якими полями пов'язані сутності, і задається у форматі, схожому на фільтр для секції `select` уgetList. Ключами та значеннями є імена полів із префіксами:
|
| Четвертий, додатковий | можна вказати тип підключення таблиці`join_type`- LEFT (за замовчуванням), RIGHT, INNER. |
Тепер можна скористатися описаним ставленням під час вибірки даних:
Перехід у сутність Автор здійснюється записом "AUTHOR." - вказується ім'я Reference поля, і після точки контекст перемикаються на цю сутність. Далі можна вказати ім'я поля з цієї сутності, у тому числі Reference, перейшовши таким чином ще далі та утворивши нове підключення таблиці:
Щоб імена полів різних сутностей не перетиналися, система генерує унікальні аліаси для сутностей, що підключаються, часом не дуже читаються. У таких випадках можна використовувати вже знайоме вам перепризначення аліасів:
І, аналогічно вихідної сутності, можна використовувати символ'*'для вибірки всіх скалярних полів сутності, за бажанням така використовуючи скорочення аліасів:
Як було згадано вище, умови зв'язування сутностей описуються подібно до фільтру. Це означає, що можна поєднувати таблиці по кількох полях, а також застосовувати SqlExpression:
ПолеReferenceField, як і інші поля, можна описувати під час вибірки даних у секції `runtime` і використовувати для підключення інших сутностей, з якими спочатку відносини не описані.
При частому використанні поля сусідньої сутності можна скористатися ExpressionField та визначити віддалене поле як локальне:
У даному прикладі різниця неочевидна, але якщо замість AUTHOR.NAME у вас буде більш довгий ланцюжок переходів, то використовувати одне коротке ім'я виявиться зручним.
Відношення 1:N або зворотний Reference
Справа в тому, що описаного Reference по суті книги вже достатньо для двосторонньої вибірки, потрібно лише використовувати спеціальний синтаксис:
Замість імені Reference потрібно вказати "Назва сутності, у якої є Reference на поточну сутність": "Ім'я референсу на поточну сутність". Після такої конструкції контекст перемикається на сутність Книга, і в ній вже можна вибрати поле TITLE та інші поля.
Відносини M:N
Описуємо сутність тегів:
Щоб зв'язати цю сутність з Книгами за принципом N:M (одна книга може мати кілька тегів, один тег може бути пов'язаний з кількома книгами), необхідно створити проміжну сутність з таблицею в БД, де зберігатимуться дані про зв'язки книг з тегами.
Все, що в даному випадку необхідно від цієї сутності, це зберігати зв'язок "ID книги - ID тега", а відповідні ReferenceField допоможуть програмно описати цей зв'язок.
Сама по собі проміжна сутність може бути нецікавою, типові завдання в даному випадку - це отриматиСписок тегів для книги або отримати список книг за тегом. Вирішуються за допомогою описаних вище методів роботи з Reference:
Запис`SomePartner\MyBooksCatalog\BookTag:BOOK.TAG.NAME`може здатися складним, але при розгляді його поетапно все має прояснитися:
| Параметри | Опис |
| BookTable::getList | вихідна сутність - BookTable |
| SomePartner\MyBooksCatalog\BookTag:BOOK | перехід до сутності BookTag через її референс BOOK, поточна сутність - BookTag |
| TAG | перехід по референсу TAG із BookTag, поточна сутність - Tag |
| NAME | поле з поточної сутності Tag |
Для отримання книг з певним тегом ланцюжок виклику буде дуже схожим:
Таким чином, використовуючи два види переходу між сутностями – REFERENCE та Entity: REFERENCE – можна досить легко дістатися до потрібної зв'язаної інформації.