Вступление

В качестве подопытного выступает модель Model_User, которую мы будем постепенно связывать с другими моделями. Настройку будем вести от простого к сложному, в начале у нас все по умолчанию. По мере освоения материала будем усложнять задачу нестандартными именами полей и связей. Вся работа происходит в статическом методе initialize(Jelly_Meta $meta), в котором описываются все специфические свойства модели. Прочитайте предыдущую статью, если не помните, как инициализируются модели в Jelly. Поля связей принципиально ничего не отличаются, только свойства (параметры для конструктора) в них немного другие.

Связь типа “Один-ко-многим” (HasMany)

Пусть имеется модель Model_User, с которой ассоциируются статьи (один пользователь может иметь несколько статей).

Короткая форма:

   'articles' => new Field_HasMany

В результате будет автоматически вычислено, что на другом конце связи находится модель Model_Article, внешний ключ – user_id.

Расширенная форма:

   'articles' => new Field_HasMany(array(
      'foreign'   => 'article.user_id'
   ))

Здесь мы уже описали имена модели и внешнего ключа, разделив их точкой. Можно укоротить запись:

   'articles' => new Field_HasMany(array(
      'foreign'   => 'article'
   ))

Опустив имя внешнего ключа, мы подразумеваем автоматическое вычисление его имени. В общем, это эквивалентно записи

   'articles' => new Field_HasMany(array(
      'foreign'   => 'article.user:foreign_key'
   ))

Jelly возьмет настройки модели Model_User для извлечения имени внешнего ключа. По умолчанию это имя модели + ‘_id’ (как и в ORM).

Изменить имя внешнего ключа для модели можно с помощью метода foreign_key(), например foreign_key('user_key').

Связь типа “Один-к-одному” (HasOne)

По сути это частный случай связи HasMany, и синтаксис такой же.

Связь типа “Много-к-одному” (BelongsTo)

Главное отличие (в плане структуры таблицы) от HasMany в том, что внешний ключ расположен в данной модели. Для связи пользователь-статьи это означает, что внешний ключ расположен в модели Model_Article, и участвует в определении связи. Соответственно короткая запись:

   'user' => new Field_BelongsTo

означает, что при обращении к $article->user произойдет попытка загрузить модель Model_User по значению ключа user_id в модели Model_Article.
Если предположить, что связь должна называться ‘author‘, а внешний ключ называется author_id и ссылается на первичный ключ id в модели Model_User, то получится такое объявление:

   'author' => new Field_BelongsTo(array(
      'foreign'  => 'user.id',
      'column'  => 'author_id',
   ))

Свойство foreign содержит все, что касается связанной модели (имя и внешний ключ), а column – имя поля в данной модели. Думаю, всем понятно, почему column отсутствует в связях HasMany и HasOne Если значение для column не указано, оно генерируется на основании указанного имени модели с прибавкой суффикса ‘_id‘, т.е. user_id в данном случае. Обратите внимание, что используется не имя связи, а имя модели!

Конечно, для свойства foreign можно (и нужно – это более гибкая запись) использовать ‘user.:primary_key‘ или просто ‘user‘.

Связь “Много-ко-многим” (ManyToMany)

Этот тип связи характеризуется выносом внешних ключей обеих связанных моделей в промежуточную таблицу (как правило, эта таблица только из этих ключей и состоит). Пусть это будет извечное пользователи-роли с промежуточной таблицей roles_users.
Короткая запись:

   'role' => new Field_ManyToMany

В результате связь будет основана на предположении, что на другом конце находится модель Model_Role, а промежуточная таблица roles_users содержит ключи user_id и role_id. Имя промежуточной модели формируется по такому же принципу, что в ORM.

Предположим, что роли находятся в таблице rolez (а модель все та же – Model_Role) с первичным ключом role_id, промежуточная таблица users_roles, а внешние ключи называются user_key и role_key. В таком случае надо использовать полную запись связи:

   'rolez' => new Field_ManyToMany(array(
      'foreign'  => 'role.role_id',
      'through'  => array(
         'model'     => 'users_roles',
         'columns'  => array(
             'user_key',
             'role_key'
         )
      ),
   ))

Итак, если свойство foreign нам уже знакомо (обозначаем настройки для связи с моделью Model_Role, как в HasMany), то свойство through в новинку. Это массив, который в наиболее полном варианте должен содержать ключи ‘model‘ (имя промежуточной модели или таблицы) и ‘columns‘ (имена внешних ключей для промежуточной таблицы). Порядок перечисления внешних ключей важен – сперва идет имя внешнего ключа от текущей модели (т.е. при объявлении связи в модели Model_Role мы бы их поменяли местами).
Есть и упрощенный вариант – указать только имя промежуточной модели/таблицы:

   'rolez' => new Field_ManyToMany(array(
      'foreign'  => 'role.role_id',
      'through'  => 'users_roles'
   ))

В этом случае внешние ключи будут вычислены как user.:primary_key и role.:primary_key.

Заключение

Давайте представим себе, как будет выглядеть условная модель Model_User со связями:

class Model_User extends Jelly_Model
{
   public static function initialize(Jelly_Meta $meta)
   {
      $meta->name_key('username')
         ->sorting(array('username' => 'ASC'))
         ->fields(array(
            'id' => new Field_Primary,
            'username' => new Field_String(array(
               'unique' => TRUE
            )),
            'password' => new Field_Password,
            'email' => new Field_Email(array(
               'unique' => TRUE
            )),
         // user has many articles
            'articles' => new Field_HasMany(array(
               'foreign'   => 'article.user_id'
            )),
         // user has one profile
            'profile'  => new Field_HasOne(array(
               'foreign'  => 'user_profile'
            )),
         // user has and belongs to many roles
            'roles' => new Field_ManyToMany(array(
               'foreign'  => 'role',
               'through'  => array(
                  'model'     => 'users_roles',
                  'columns'  => array(
                     'user_id',
                     'role_id'
                  ),
               ),
            )),
            'group'    => new Field_BelongsTo(array(
               'foreign'   => 'user_group',
               'column'   => 'group_id'
            )),
         ))->foreign_key('user_id');
    } 
}

Думаю, тут все понятно

Сообщаем о наличии связей в модели

Как мы помним, в модуле Sprig все используемые поля таблицы объявляются в методе _init(), и поля связей тут не исключение. Есть четыре класса для описания различных типов связей (тут все похоже на связи в ORM, так что я сильно их расписывать не буду):

• Sprig_Field_HasOne
• Sprig_Field_HasMany
• Sprig_Field_BelongsTo
• Sprig_Field_ManyToMany

Названия говорят сами за себя. Поскольку в каждой связи участвует две стороны, нет смысла рассматривать классы по отдельности, так что давайте возьмем следующую ситуацию:

1. Есть записи в блоге (модель blog).
2. Есть тэги, которые вешаются на записи блога (модель tag).
3. Есть пользователи (модель user).
4. Есть статистика по пользователям блога. Т.к. она не относится непосредственно к модели пользователя (мы предполагаем, что есть и другие модули, где используется user), выделяем ее в отдельную модель (userinfo).

В упрощенном виде схема получится примерно такая:

Схема таблиц

Тут использованы соглашения по умолчанию для ORM (первичный ключ называется `id`, внешние ключи формируются как название модели + суффикс `_id`, и т.д.). Какие модели мы в итоге получим? Давайте я сразу приведу их код, а после разберем типы связей по отдельности.

// пользователи
class Model_User extends Sprig
{
	protected function _init() {
		$this->_fields += array(
			'id'               => new Sprig_Field_Auto,
			'username'   => new Sprig_Field_Char,
			'email'         => new Sprig_Field_Email,
			'userinfo'      => new Sprig_Field_HasOne,
			'articles'       => new Sprig_Field_HasMany,
		);
	}
}
 
// статьи
class Model_Article extends Sprig
{
	protected function _init() {
		$this->_fields += array(
			'id'              => new Sprig_Field_Auto,
			'title'           => new Sprig_Field_Char,
			'text'           => new Sprig_Field_Text,
			'user'          => new Sprig_Field_BelongsTo,
			'tags'          => new Sprig_Field_ManyToMany,
		);
	}
}
 
// тэги
class Model_Tag extends Sprig
{
	protected function _init() {
		$this->_fields += array(
			'id'            => new Sprig_Field_Auto,
			'name'      => new Sprig_Field_Char,
			'articles'    => new Sprig_Field_ManyToMany,
		);
	}
}
 
// доп. информация о пользователях
class Model_Userinfo extends Sprig
{
	protected function _init() {
		$this->_fields += array(
			'id'       => new Sprig_Field_Auto,
			'data'   => new Sprig_Field_Text,
			'user'   => new Sprig_Field_BelongsTo,
		);
	}
}

Условно все поля можно разбить на две категории – реальные поля и псевдополя. Примеры реальных полей – `id`, `email` и `username` в модели Model_User, они присутствуют в таблице. Псевдополя являются результатом наличия связей с другими моделями. Например, поля `articles` и `userinfo`, которые не могут быть сохранены в БД в явном виде. Для них свойство $in_db установлено в FALSE. Не стоит путать внешний ключ (например, `user_id` в таблице `articles`) с псевдополем `user` – в первом случае мы просто работаем с численным значением, второй вариант дает возможность получить связанный объект.

HasOne

Примером данной связи будет наличие доп. информации у пользователя. В модели Model_User объявлено псевдополе $userinfo:

'userinfo'	=> new Sprig_Field_HasOne,

Так как никаких дополнительных параметров при создании псевдополя не передавалось, то при обращении к нему будут автоматически вычислены следующие свойства связи:

• Имя связанной модели `model` будет `userinfo` (по названию псевдополя).
• Имя внешнего ключа в той модели (`column`) определится как `user_id` (имя текущей модели + '_id').

Схема определения имени внешнего ключа не является жестко фиксированной – используется метод fk($table = NULL) модели. Вы можете его переопределить, чтобы, к примеру, возвращать ‘user_key‘. Кроме того, если в Вашей модели используется нестандартный первичный ключ (например ‘key‘), то по умолчанию метод pk() будет возвращать что-то вроде ‘user_key‘ вместо ‘user_id‘ – будьте внимательны!

Теоретически, теперь мы можем попробовать обратиться к свойству $user->userinfo:

$user = Sprig::factory('user', array('id' => 1));
echo $user->userinfo->load()->data;

К сожалению, результата не будет. Что-то не так? Методом проб и ошибок определяем, что метод load() не возвращает ожидаемое (а мы предполагаем модель Userinfo, где поле ‘user_id‘ равно 1). А проблема вот в чем – надо объявить данную связь на другой ее стороне, т.е. собственно в модели Userinfo. Это связь типа BelongsTo, так что имеет смысл перейти к ней.

BelongsTo

Через данный тип связи объявляем, что каждый объект Userinfo привязан к родительскому объекту User, в нашем случае через поле ‘user_id‘. Так как пока что все свойства рассматриваемых моделей (ключи, имена связей и т.д.) максимально простые, то и объявление будет коротким:

'user'   => new Sprig_Field_BelongsTo,

Автоматически заполняются свойства связи:

• ‘model‘ – имя связанной модели, в данном случае ‘user‘.
• ‘column‘ – имя поля внешнего ключа, получаем через метод fk() модели Model_User (по умолчанию вернет ‘user_id‘).

Поскольку данный тип связи используется не только для HasOne, но и с HasMany, аналогичное объявление мы сделали в модели Model_Article для связи с Model_User:

'user'   => new Sprig_Field_BelongsTo,

Теперь можно вызывать $userinfo->user->load()->username, причем обратную сторону связи в данном случае прописывать необязательно. Таким образом, делаем вполне логичный вывод – связь обязательно должна быть прописана в пассивной модели (т.е. в модели, в которую переходит внешний ключ).

HasMany

Собственно тут тоже ничего сложного, вот так в Model_User объявлено, что каждый пользователь может понаписать множество статей в блоге:

'articles'       => new Sprig_Field_HasMany,

“На автопилоте” определяется свойство ‘model‘ – имя модели, получаем как название связи в единственном числе (через Inflector::singular()) – ‘article‘. Свойство ‘column‘ бессмысленно, т.к. в результате данной связи в таблице никаких полей не добавляется.

ManyToMany

Тут тоже все просто и скучно, в модели Model_Article объявляем о тэгах:

'tags'          => new Sprig_Field_ManyToMany,

• Свойство ‘model‘ получится как ‘tag‘ (имя связи в единственном числе).
• Свойство ‘through‘ (имя промежуточной таблицы) вычисляется аналогично ORM: берем имена таблиц (в данном случае это ‘articles‘ и ‘tags‘), ставим по алфавиту и разделяем знаком подчеркивания, т.е. ‘articles_tags‘ в итоге.
• Свойство ‘column‘ не заполняется ввиду неактуальности.

Что любопытно – после вычисления свойства ‘through‘ для пары статья-тэг становится доступным статическое свойство Sprig::$_relations['article_tag'], которое содержит имя промежуточной таблицы. Таким образом, если из модели Model_Tag обратиться к свойству articles, промежуточная таблица будет взята оттуда. Теоретически это должно позволить менять одну из главных настроек связи ManyToMany только в одном месте, но у меня это не вызвало особого интереса. Наверное проще указать ‘through‘ вручную в двух моделях, зато это будет предсказуемо.

Ленивая загрузка

Наверняка вы обратили внимание на метод load(), который иногда используется после обращения к связанным объектам. Очевидно, что данный метод вызывает загрузку записей, т.е. непосредственно $user->userinfo, к примеру, вернет только экземпляр Database_Query_Builder_Select с примененными параметрами выборки (с условием where('user_id', '=', 1)). В общем, lazy loading к вашим услугам! Правда, это актуально только для HasOne и BelongsTo.

Идем дальше. Наверняка вы помните, как осуществляется выборка связанных объектов в ORM. К примеру, $user->articles->where('approved', '=', 1)->find_all() позволяет выбрать только утвержденные статьи пользователя. Однако в Sprig не все так просто. К сожалению, непосредственный вызов $user->articles приведет к выборке всех статей пользователя, метод where() здесь просто некуда “воткнуть”. Единственное, что предлагается нам – все тот же метод load(). В результате то, что в ORM получается достаточно элегантно, в Sprig выглядит несколько неуклюже:

$query = DB::select()->where('user_id', '=', $user->pk())->where('approved', '=', 1);
$articles = Sprig::factory('article')->load($query, FALSE);

Сперва подготовили условия (авторство и наличие флага “утверждено”), потом подставили в метод load(). Не забудьте про второй параметр, т.к. по умолчанию количество записей ограничивается одной. Впрочем, можно установить нужный лимит записей, например для разбивки на страницы (т.е. для пагинатора).

Это актуально и для безусловных выборок. Например, получаем всех пользователей:

$users = Sprig::factory('user')->load(NULL, FALSE);

Да, это работает. Но теряется вся красота и прозрачность, которая сопутствует ORM. Надеюсь, это будет исправлено в следующих коммитах.

Усложняем задачу

Конечно, далеко не всегда получается использовать именования таблиц, полей и т.д., которые по умолчанию подходят под соглашения, будь то ORM или Sprig. Поэтому давайте изменим рассматриваемую схему, которая во второй редакции будет выглядеть вот так:

Список изменений следующий.

• Таблица articles_tags переименована в arttags.
• Первичный ключ в articles теперь называется articleid.
• Внешний ключ user_id переименован в author_id.

Теперь посмотрим, как изменятся коды моделей. Для начала разберемся с переименованием первичного ключа. Обычно (и в ORM мы используем такой подход) для этого есть специальное свойство $_primary_key. Но одна из особенностей Sprig – некоторые типы полей могут быть заранее обозначены как часть первичного ключа (их свойство $primary установлено в TRUE). Это действительно для поля Sprig_Field_Auto, поэтому поле `articleid` будет добавлено в свойство $_primary_key автоматически. Другое дело, что в методе _init(), где это поле объявляется, необходимо указать актуальное имя:

protected function _init() {
	$this->_fields += array(
		'articleid'			=> new Sprig_Field_Auto,
		...

Стоит обратить внимание, что текущая версия Sprig не осуществляет проверку при добавлении поля в список первичного ключа, так что в случае прописывания свойства $_primary_key вручную скорее всего одно и то же поле будет добавлено туда дважды.

Идем дальше. Для связи с пользователем модель Article теперь использует внешний ключ `author_id`. В связи с этим меняем объявление поля в методе _init():

'user'	=> new Sprig_Field_BelongsTo(array('column' => 'author_id'),

Как мы видим, чтобы переопределить дефолтные названия для внешних ключей, надо использовать параметр column. Сделаем еще одно изменение – пусть доступ к модели User будет осуществляться по псевдополю ‘author‘ (т.е. $article->author вместо $article->user, что более логично). Для этого надо переименовать имя поля, а также явно указать название связанной модели, которое ранее вычислялось автоматически:

'author'	=> new Sprig_Field_BelongsTo(array('model' => 'user', 'column' => 'author_id'),

Ну и напоследок – указываем в явном виде новое имя промежуточной модели для связи ManyToMany:

'tags'=> new Sprig_Field_ManyToMany(array('through' => 'arttags')),

Прописали? Проверяем, работает?! Ан нет, не работает. Вспомните алгоритм вычисления наименования внешнего ключа – по умолчанию все зависит от первичого ключа. Поэтому JOIN таблиц arttags и tags будет осуществляться по некорректному полю ‘article_articleid‘. Как этого избежать, я уже упоминал – надо переопределить метод fk(), чем нам и придется заняться:

public function fk($table = NULL)
{
	$key = 'article_id';
 
	if ($table)
	{
		if ($table === TRUE)
		{
			$table = $this->_table;
		}
		return $table.'.'.$key;
	}
 
	return $key;
}

Конечно, не самое красивое решение. Во первых, приходится копировать исходный метод полностью, а хотелось бы в полной мере попользоваться наследованием, дабы в своем методе (условно говоря) вычислить переменную $key (или сохранить ее в каком-нибудь свойстве с говорящим названием $_foreign_key) и далее вызвать parent::fk(). Кроме того, вдруг в какой-нибудь другой таблице внешний ключ будет переходить под другим названием? Единственное приходящее мне в данный момент решение – добавление switch ... case с перечислением известных вариантов значений для переменной $table (по крайней мере для ManyToMany метод fk() всегда использует данный параметр). Вспоминается поговорка про мышей и кактус

На этом все

Согласитесь, налицо существенные недостатки и никаких преимуществ перед ORM. Так почему я пишу о данном модуле, а не придумываю новый повод написать очередную статью про ORM? Намекну, что главная сила Sprig не в связях. Sprig удобен тем, что мы унифицируем работу с полями модели/таблицы – генерацию и обработку форм в первую очередь. Но это уже тема для следующей – итоговой – статьи, в которой я покажу, что нам собственно делать с предоставляемыми возможностями.

С чего начать?

Перед построением моделей обязательно понимание структуры таблиц в БД, с которой наши модели неразрывно связаны. И если отдельно взятую таблицу мы уже научились проецировать в модель ORM, то теперь надо их связать между собой. Давайте сперва рассмотрим теорию. Существует три вида связей между таблицами, описание которых мы сейчас и рассмотрим. А потом перейдем к использованию предоставляемых нам ORM‘ом возможностей.

Один-к-одному (1-1)

Это достаточно редкий вид связи, когда каждой записи в первой таблице соответствует только одна запись из второй, и наоборот. Теоретически эти таблицы могут быть объединены в одну (первичные ключи в них совпадают), но зачастую в целях оптимизации их разбивают на части. Например, если имеется таблица со списком статей и стоит выбор, где хранить информацию со статистикой просмотра этих статей, вполне логичным решением будет создание отдельной таблицы со связью один-к-одному. В этом случае дополнительная таблица выглядит как “пристройка” к основной. Если говорить в терминах фреймворка, то мы можем создавать вспомогательные таблицы вокруг таблицы users из состава модуля Auth (например, я ранее упоминал о таблице user_details с дополнительными анкетными данными пользователей). Опять же, в этом случае нам не придется вносить изменения как в модель, так и в структуру таблицы.

Предположим, у нас есть схема из этих двух таблиц:

Связь один-к-одному

Создадим заготовки для моделей:

// models/User.php
class User_Model extends ORM {
 
}
// models/User_Detail.php
class User_Detail_Model extends ORM {
    // Relationships
    protected $has_one = array('user');
    protected $primary_key = 'user_id';

Скорее всего у вас подключен модуль Auth и модель User_Model уже существует. Поскольку мы его будем рассматривать как сторонний (точнее как часть фреймворка), вносить в него изменения нежелательно и даже бессмысленно. А если модели нет, создаете заготовку как в моем примере – модель будет совершенно работоспособна, но ничего конкретного мы в нее не вносим. Пусть вспомогательные модели под нее подстраиваются.

В модели User_Details всего две строчки. Первая описывает собственно связь. Все связи модели хранятся в свойствах в виде массивов. Каждому типу связи соответствует свой массив. В данном случае мы заполняем свойство $has_one. Таких связей может быть несколько, например так:

protected $has_one = array('user', 'anything_else');

Вторая строчка описывает имя первичного ключа. По умолчанию свойство $primary_key установлено в ‘id‘, как и рекомендует нам документация по ORM, однако мы можем обговорить имя ключа, чем и воспользуемся. При связи один-к-одному такое часто бывает. Кроме этих двух строк ничего не надо. Пишем где-нибудь в контроллере:

// получаем анкетные данные пользователя 1
$ud = ORM::factory('user_details', 1);
// зачем над данные без самого пользователя?
// обращаемся к нему как к обычному свойству объекта
$user = $ud->user;

Обратите внимание, что хотя связь между таблицами в принципе равнозначная, из модели User_Model мы так получить User_Details не сможем (ведь в ней не описана эта связь в свойстве $has_one). Еще один важный момент: как мы связь назвали при ее описании в свойстве $has_one, под таким именем она нам будет доступна. Теперь понятно, что было бы, если бы внешние ключи назывались не user или article, а user_id и article_id?

Еще одно примечание. В официальной документации в качестве примера приводится связь между моделью Blog_Post_Model и User_Model из соображений, что одному посту в блоге соответствует один пользователь (автор). Я с этим категорически не согласен, т.к. связь один-к-одному должна быть одинаковой на обоих концах, а у пользователя может быть несколько постов, так что там связь типа один-ко-многим. Такая вот оппозиция

Один-ко-многим (1-N)

Данная связь означает, что каждой записи в одной таблице может соответствовать несколько записей из другой таблицы. Это самая распространенная связь между таблицами. На схеме ниже рассмотрено взаимодействие между темами на форуме и комментариями к ним:

Связь один-ко-многим

class Post_Model extends ORM {
	protected $db = 'forum';
	protected $has_many = array('comments');
}
 
class Comment_Model extends ORM {
	protected $db = 'forum';
	protected $belongs_to = array('post');
}

Думаю, здесь надо объяснить немного поподробнее. Сперва насчет переменной $db – в ней до вызова конструктора хранится имя профиля из файла(ов) config/database.php. Я уже писал о том, что в каждом отдельно взятом модуле хочу сделать свои префиксы для таблиц. Поэтому на схеме таблицы названы с префиксом ‘forum_‘. Конечно, можно было использовать свойство $table_name и указать имя таблицы, но тогда это пришлось бы делать для каждой модели. Кроме того, такой подход заставит нас переделывать все модели, если префикс поменяется (в идеале подобный выбор предоставляется пользователю во время инсталляции проекта). Другой вариант еще хуже – назвать модели в соответствии с именами таблиц, т.е. Forum_Post_Model и Forum_Comment_Model. Недостатки те же, да еще и имя класса увеличилось. Поэтому остановимся на префиксах. Если у вас их нет (или вдруг вы от них отказались), то просто не используйте опцию table_prefix в настройках профиля подключения к БД – и больше ничего менять не придется.

Далее – новые для нас свойства $has_many и $belongs_to. Их использование ничем не отличается от $has_one. Для таблицы, которая как бы является родительской (комментарии принадлежат статье, а не статьи комментарию) используем $has_many (дословно – “имеет много“), для “дочерней” таблицы – $belongs_to (“относится к“). На уровне структуры таблиц это сопровождается добавлением первичного ключа родительской таблицы (в нашем случае это forum_posts.id) в дочернюю в виде внешнего ключа post_id. Типичный механизм – имя таблицы в единственном числе (post, т.к. префикс мы привычно отбрасываем) плюс суффикс ‘_id‘. Опять же, не всегда получается называть поля как мы хотим, поэтому ниже я покажу дополнительные свойства для жесткого указания имен внешних ключей.

Часто люди путаются при заполнении связей модели, где употреблять имя в единственном числе, а где во множественном. Следует рассуждать логически: статья имеет много комментариев, следовательно $has_many = array(‘comments’). Аналогично комментарий относится к статье, т.е. $belongs_to(‘post’). Связи один-к-одному всегда в единственном числе. Проще всего запомнить – если в названии связи есть слово many, то употребляем множественное число (т.е. связь неоднозначная, на противоположном ее конце несколько объектов).

Использование аналогично связи один-к-одному, только будьте готовы к тому, что на в результате можем получить массив записей:

// ищем пост №1
$post = ORM::factory('post', 1);
// выводим на экран текст топика
echo $post->text."<br />";
// получаем комментарии топика
// !! это не ORM-объект, а ORM_Iterator !!
$comments = $post->comments;
// далее в цикле пробегаемся по комментариям топика
foreach($comments as $comment)
    echo $comment->text."<br />";
// а теперь получаем топик, которому принадлежит комментарий №2
$comment = ORM::factory('comment', 2);
echo $comment->post->id;

Запомните, если связь неоднозначная, т.е. мы ждем несколько объектов, связанных с нашим, в результате получим не ORM-объект, а экземпляр класса ORM_Iterator. Для простоты можете рассматривать его как массив ORM-объектов нужного вам класса. Если же вас смущает использование непонятного класса, описание которого отсутствует (на данный момент) в официальной документации – можете просто превратить его в настоящий массив с помощью метода as_array().

Много-ко-многим (M-N)

Этот тип связи появляется, когда между связанными таблицами нет однозначности в обе стороны, т.е. каждой строке из одной таблицы может соответствовать несколько записей из другой, и наоборот. Типичный пример – у пользователя может быть несколько ролей (так было в модуле Auth, идущем в составе Kohana 2.3.x), каждая роль может быть присвоена нескольким пользователям. Поэтому простым перекидыванием первичного ключа из одной таблицы в другую связь не наладить – нет однозначности. Решение – создание промежуточной таблицы (pivot table) между ними, в которую добавляются первичные ключи обеих таблиц. Обычно кроме этих полей в ней ничего нет.

Связь много-ко-многим

Имя для промежуточной таблицы составляется из расставленных в алфавитном порядке названий связанных таблиц, объединенных знаком подчеркивания. Первичный ключ состоит из внешних ключей таблиц users и forum_roles (user_id и role_id соответственно). По сути таблица roles_users служит только для хранения пар пользователь-роль, чтобы из одной таблицы можно было “перескочить” в другую. Давайте посмотрим, как это выглядит в терминах Kohana:

class User_Model extends ORM {
	protected $has_and_belongs_to_many = array('roles');
 
class Role_Model extends ORM {
	protected $db = 'forum';
	protected $has_and_belongs_to_many = array('users');
}

Как видно, для указания связи много-ко-многим используется свойство $has_and_belongs_to_many (часто на форумах используется термин HABTM, аббревиатура от данного названия). Обратите внимание, что промежуточная таблица roles_users вообще не участвует в процессе создания моделей ORM, главное – чтобы ее имя и названия полей соответствовали требования ORM (либо были указаны явно). В результате получим всех администраторов системы (id=1):

$role = ORM::factory('role', 1);
foreach ($role->users as $user)
   echo $user->username."<br />";

И все-таки, насколько неудобно использовать id при создании объектов! Насколько более понятны и близки нам “говорящие” поля, такие как username или name. Естественно, разработчики предусмотрели способ передавать при создании экземпляра модели не идентификатор, а произвольную строку. Для этого надо переопределить метод unique_key($id). Можете просто поковырять модель User_Model в модуле Auth, там это уже сделано.

Но что же делать, если в промежуточной таблице необходимо хранить не только внешние ключи? Например, в рассматриваемом нами случае с ролями могут присутствовать поля created (время добавления роли) и expired (время окончания действия роли). В таком случае вместо одной связи много-ко-многим между двумя таблицами мы получаем две связи один-ко-многим между тремя:

Во что превратилась связь много-ко-многим

class User_Model extends ORM {
	protected $has_many = array('assigned_roles');
 
class Role_Model extends ORM {
	protected $db = 'forum';
	protected $has_many = array('assigned_roles');
}
 
class Assigned_Role_Model extends ORM {
	protected $db = 'forum';
	protected $belongs_to = array('users', 'roles');
}

В этом случае мы рассматриваем такую связь как две: наличие нескольких назначенных ролей пользователю и возможность назначения роли несколько раз (предполагается, что различным пользователям). Кстати, никто не мешает комбинировать оба варианта (только класс и таблица должны называться forum_roles_users, иначе запрос не сформируется).

“Сквозное” один-ко-многим

Рассмотренный выше вариант преобразования HABTM в два has_many доступен в более компактном виде. Посмотрите на такую запись:

class User_Model extends ORM {
	protected $has_many = array('roles' => 'assigned_roles');
 
class Role_Model extends ORM {
	protected $db = 'forum';
	protected $has_many = array('users' => 'assigned_roles');
}
 
class Assigned_Role_Model extends ORM {
	protected $db = 'forum';
	protected $belongs_to = array('users', 'roles');
}

Теперь в $has_many мы записываем как промежуточную модель (`assigned_roles`), так и “конечную” (`roles` и `users`) как бы с использованием псевдонимов (aliasing). Теперь можно обращаться как к $user->roles, так и к $user->assigned_roles.

Это конечно удобно, но взамен мы теряем возможность использовать псевдонимы для “настоящих” связей один-ко-многим. Даже не знаю, стоило ли оно того. Впрочем, в версии 2.4 для “сквозных” связей будет предусмотрено отдельное свойство $has_many_through.

Работа со связями

Как заполнять таблицы мы знаем. А как создавать связи между конкретными записями? Как добавить пользователю X роль Y, добавить комментарий №4 именно в топик №13? Все довольно просто. Сейчас мы рассмотрим доступные нам возможности.

• В случае связи один-к-одному все достаточно просто: в дочернюю таблицу необходимо подставить ключ из родительской. Например, при сохранении анкетных данных в поле $user_details->user_id надо подставить что-то вроде $user->id, где $user – ORM-модель сохраняемого пользователя. Аналогичные действия надо предпринять при сохранении объекта, связанного с другим через $belongs_to.
• Несколько сложнее добавление связи в случае много-ко-многим. Для этого в ORM добавили специальный метод add(). Использовать надо так:
  

  // создаем объект пользователя с id=$id
  $user = ORM::factory('user', $id);
  // добавляем ему роль с id=$roleid
  $user->add(ORM::factory('role', $roleid));

  
  В качестве параметра передается экземпляр ORM-модели, с которой надо связать объект. Для проверки существования связи с данной моделью (проверка на дублирование) доступен метод has(), а для удаления связи – remove(). Оба они также принимают в качестве параметра проверяемый/удаляемый объект.

  Возвращаясь к удобству переопределения метода unique_value($id): насколько ORM::factory(‘role’, ‘admin’) читабельнее, чем ORM::factory(‘role’, 1)!

• Специальный метод для удаления связи существует только для много-ко-многим. Если вы удалите топик, комментарии к нему Kohana удалять не будет. Либо об этом позаботитесь вы сами (программно), либо (что проще) об этом позаботится СУБД, если вы при создании таблиц будете использовать конструкции типа ON DELETE CASCADE.

Custom’изация ORM-моделей

Итак, если какие-то параметры (названия таблиц, ключей и т.д.) у нас отличаются от ожидаемых по правилам ORM, есть несколько способов вручную указать, что и куда подставлять. Часть свойств я упоминал в предыдущей статье, сейчас расскажу про оставшиеся, отвечающие за взаимодействие с другими моделями.

$load_with. Позволяет указать, какие модели загружать вместе с данной автоматически. Представляет из себя массив связей. Например, чтобы при создании модели User_Detail загружались еще и данные этого пользователя, просто указываем $load_with = array(‘user’). Совместная загрузка будет работать только с однозначными связями, т.е. если указываемая модель была занесена нами в $has_one или $belongs_to. Поэтому в модели Comment_Model мы можем указать загрузку модели Post_Model, но не наоборот. По сути мы сразу вызываем join-запрос, не дожидаясь “ленивой” загрузки связанной модели в дальнейшем. Рекомендую не увлекаться этим свойством, т.к. не все загружаемые вместе с текущим объектом модели вам пригодятся.

$foreign_key. Массив указанных вручную внешних ключей для модели. Используется только для связей один-ко-многим (в других случаях внешних ключей по сути нет). Если в дочерней модели имя поля, являющегося внешним ключом, не соответствует концепии ORM (т.е. не имя_родительской_модели + суффикс ‘_id‘), то необходимо указать в данном свойстве истинное имя поля. Предположим, что в рассмотренной нами выше схеме внешний ключ таблицы forum_comments называется new_post_id:

Схема комментарии - топики с измененным внешним ключом

class Post_Model extends ORM {
	protected $db = 'forum';
	protected $has_many = array('comments');
	protected $foreign_key = array('comments'=>'new_post_id');
}
 
class Comment_Model extends ORM {
	protected $db = 'forum';
	protected $belongs_to = array('post');
	protected $foreign_key = array('post'=>'new_post_id');
}

Обратите внимание, что имя внешнего ключа надо прописывать в обеих моделях! Если в модели Post_Model вы это не сделаете, то при попытке получить все комментарии топика (что-то вроде $post->comments) произойдет ошибка SQL-запроса. Возможно, не совсем логичное решение разработчиков, т.к. при изменении внутренней структуры дочерней модели изменения придется внести и в родительскую. Также запомните, что ключи в массиве $foreign_key должны совпадать с указанными в связях, т.е. ‘post‘ для Comment_Model и ‘comments‘ для Post_Model.

Свойство появилось только в версии 2.3.2!

Ну, и напоследок – псевдонимы (aliasing).
Иногда имя таблицы, с которой связывается текущая таблица, не выражает ту роль, которую она играет. Типичный пример – таблица users. Пользователь может быть автором, модератором, редактором, голосующим и т.д. Кроме того, в рамках одной таблицы может быть несколько внешних ключей к одной и той же таблице. Как быть в этом случае? Помогут псевдонимы:

class Article_Model extends ORM {
	// у статьи может быть автор и редактор, причем это разные люди
	protected $belongs_to = array('author'=>'user', 'redactor'=>'user');
}

Как видите, все достаточно просто. Сначала пишем имя связи (т.е. роль, которую играет модель), а далее – само имя модели (причем в зависимости от типа связи оно может быть в единственном или множественном числе, как я уже упоминал). Используя эти псевдонимы, в контроллере мы можем вызывать “магические” свойства $article->author и $article->redactor.

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

protected $belongs_to = array('author'=>'user', 'redactor'=>'user', 'categories'=>'categories');

Можно смешить псевдонимы с обычными ключами:

protected $belongs_to = array('author'=>'user', 'redactor'=>'user', 'categories');

Проблемы, с которыми можно столкнуться

Использование одной таблицы в различных ролях. Опять же, центральная в моей схеме БД таблица – users. Мы можем создать одну модель и нафаршировать ее связями со всеми таблицами, использующими ее данные (если вспомнить схему, приведенную мной в статье о модуле “форум“, становится понятно, о чем это я. И это только один модуль!). А можем выделить роли этой таблицы и создать для каждой из них свою модель. Для указания имени таблицы, напомню, есть свойство $table_name. Например, роль “Автор” (Author) просто напрашивается для модуля “форум“, т.к. присутствует и в комментариях, и в топиках. Можно поиграться и с наследованием от базового класса, но это не всегда предсказуемо. К примеру, свойства модели при переопределении не дополняются базовыми, т.е. связи предка будут потеряны.

Применение префиксов таблиц. Если между собой связываются таблицы с различными префиксами (к примеру, users и forum_roles из схемы про много-ко-многим), то могут возникнуть проблемы с автоматическим вычислением системой имен таблиц. В первую очередь это связано именно со связями много-ко-многим. Имя промежуточной таблицы вычислится в разных моделях по-разному, и в одну из сторон связь работать не будет. В этом случае вместо forum_таблица1_таблица2 придется использовать таблица1_forum_таблица2. Это логично с точки зрения ORM, но не очень удобно, если мы хотим, чтобы все таблицы модуля начинались одинаково.

Что дальше?

Думаю, с теорией теперь более-менее ясно. В качестве закрепления попробуйте реализовать большую и сложную схему с кучей связанных между собой таблиц. В следующей статье я покажу это на примере описанной мной ранее схемы модуля “форум“.

PS. Надеюсь, я ничего не забыл, если что – традиционно тыкайте меня в ошибки в комментариях.