mirror of
https://github.com/yiisoft/yii.git
synced 2026-03-06 08:14:21 +01:00
446 lines
35 KiB
Plaintext
446 lines
35 KiB
Plaintext
Реляционная Active Record
|
||
=========================
|
||
|
||
Мы уже рассмотрели использование Active Record (AR) для выбора данных из одной таблицы базы данных.
|
||
В этом разделе мы расскажем, как использовать AR для объединения нескольких связанных таблиц и получить
|
||
объединенный набор данных.
|
||
|
||
AR полагается на метаданные об отношениях, чтобы определить, каким образом следует объединять таблицы,
|
||
поэтому для использования реляционной AR необходимо, чтобы все связи отношения первичный-внешний ключ
|
||
были четко определены между объединяемыми таблицами.
|
||
|
||
> Note|Примечание: Начиная с версии 1.0.1 можно использовать реляционную AR даже, если
|
||
> вы не определите ни одного ограничения с использованием внешних ключей в базе данных.
|
||
|
||
Для наглядности примеров в данном разделе мы будем использовать схему базы данных,
|
||
представленную на этой диаграмме сущность-отношение (ER).
|
||
|
||
|
||
|
||
> Info|Информация: Поддержка ограничений по внешнему ключу различна в разных СУБД.
|
||
>
|
||
> SQLite не поддерживает ограничений, но вы, тем не менее, можете их объявить при создании таблиц. AR может использовать
|
||
> эти данные для корректной поддержки реляционных запросов.
|
||
>
|
||
> MySQL поддерживает ограничения по внешнему ключу в движке InnoDB и не поддерживает в MyISAM, поэтому для работы с
|
||
> MySQL рекомендуется использовать InnoDB. При использовании MyISAM для осуществления
|
||
> реляционных запросов посредством AR можно поступить следующим образом:
|
||
>
|
||
> ~~~
|
||
> [sql]
|
||
> CREATE TABLE Foo
|
||
> (
|
||
> id INTEGER NOT NULL PRIMARY KEY
|
||
> );
|
||
> CREATE TABLE bar
|
||
> (
|
||
> id INTEGER NOT NULL PRIMARY KEY,
|
||
> fooID INTEGER
|
||
> COMMENT 'CONSTRAINT FOREIGN KEY (fooID) REFERENCES Foo(id)'
|
||
> );
|
||
> ~~~
|
||
> Выше мы используем ключевое слово `COMMENT` для пояснения ограничения по внешнему ключу, которое может быть использовано AR
|
||
> для распознания описанного отношения.
|
||
|
||
Объявление отношения
|
||
----------------------
|
||
|
||
Перед тем, как использовать AR для реляционных запросов, нам необходимо объяснить AR, как AR-классы связаны друг с другом.
|
||
|
||
Отношение между двумя AR-классами напрямую зависит от отношений между соответствующими таблицами базы данных. С точки
|
||
зрения БД, отношение между таблицами A и В может быть трех типов: один-ко-многим (например, `User` и `Post`), один-к-одному
|
||
(например, `User` и `Profile`) и многие-ко-многим (например, `Category` и `Post`). В AR существует четыре типа отношений:
|
||
|
||
- `BELONGS_TO`: если отношение между А и В один-ко-многим, значит В принадлежит А (например, `Post` принадлежит `User`);
|
||
|
||
- `HAS_MANY`: если отношение между таблицами А и В один-ко-многим, значит у А есть много В (например, у `User` есть много `Post`);
|
||
|
||
- `HAS_ONE`: это частный случай `HAS_MANY`, где А может иметь максимум одно В (например, у `User` есть только один `Profile`);
|
||
|
||
- `MANY_MANY`: это отношение соответствует типу отношения многие-ко-многим в БД. Поскольку многие СУБД не поддерживают непосредственно
|
||
тип отношения многие-ко-многим, требуется ассоциированная таблица для преобразования отношения многие-ко-многим в отношения один-ко-многим.
|
||
В нашей схеме базы данных, этой цели служит таблица `PostCategory`. В терминологии AR отношение `MANY_MANY` можно описать как
|
||
комбинацию `BELONGS_TO` и `HAS_MANY`. Например, `Post` принадлежит многим `Category`, а у `Category` есть много `Post`.
|
||
|
||
Объявляя отношение в AR, мы переопределяем метод [relations()|CActiveRecord::relations] класса [CActiveRecord]. Этот метод возвращает
|
||
массив с конфигурацией отношений. Каждый элемент массива представляет одно отношение в следующем формате:
|
||
|
||
~~~
|
||
[php]
|
||
'VarName'=>array('RelationType', 'ClassName', 'ForeignKey', …дополнительные параметры)
|
||
~~~
|
||
|
||
где `VarName` — имя отношения, `RelationType` указывает на один из четырех типов отношения,
|
||
`ClassName` — имя AR-класса, связанного с данным AR-классом, а
|
||
`ForeignKey` обозначает один или несколько внешних ключей, используемых для связи.
|
||
Кроме того, можно указать ряд дополнительных параметров,
|
||
о которых расскажем чуть позже.
|
||
|
||
В коде ниже показано, как объявить отношение между классами `User` и `Post`.
|
||
|
||
~~~
|
||
[php]
|
||
class Post extends CActiveRecord
|
||
{
|
||
public function relations()
|
||
{
|
||
return array(
|
||
'author'=>array(self::BELONGS_TO, 'User', 'authorID'),
|
||
'categories'=>array(self::MANY_MANY, 'Category', 'PostCategory(postID, categoryID)'),
|
||
);
|
||
}
|
||
}
|
||
|
||
class User extends CActiveRecord
|
||
{
|
||
public function relations()
|
||
{
|
||
return array(
|
||
'posts'=>array(self::HAS_MANY, 'Post', 'authorID'),
|
||
'profile'=>array(self::HAS_ONE, 'Profile', 'ownerID'),
|
||
);
|
||
}
|
||
}
|
||
~~~
|
||
|
||
> Info|Информация: Если внешний ключ составной, мы должны объединить имена полей внешнего ключа и отделить
|
||
друг от друга пробелом или запятой. Для типа отношения `MANY_MANY` имя ассоциативной таблицы также должно быть
|
||
указано во внешнем ключе. Например, отношение `categories` в модели `Post` обозначено внешним ключом `PostCategory(postID, categoryID)`.
|
||
|
||
При объявлении отношения в AR-классе для каждого отношения в класс неявно добавляется свойство. После выполнения реляционного запроса
|
||
соответствующее свойство будет заполнено связанным(-и) экземпляром(-ами) AR. Например, если `$author` представляет AR-экземпляр `User`, то
|
||
можно использовать `$author->posts` для доступа к связанным экземплярам `Post`.
|
||
|
||
Выполнение реляционного запроса
|
||
---------------------------
|
||
|
||
Самый простой способ выполнить реляционный запрос — считать реляционное свойство AR-класса. Если ранее к этому свойству никто не обращался,
|
||
то будет инициирован реляционный запрос, который соединит связанные таблицы и оставит только данные, соответствующие первичному ключу текущего
|
||
экземпляра AR. Результат запроса будет сохранен в свойстве как экземпляр(-ы) связанного класса.
|
||
Этот подход также известен, как «ленивая загрузка» (lazy loading), т.е.
|
||
реляционный запрос осуществляется только в момент первого обращения к связанным
|
||
объектам. Пример ниже показывает использование этого подхода:
|
||
|
||
~~~
|
||
[php]
|
||
// получаем пост с ID=10
|
||
$post=Post::model()->findByPk(10);
|
||
// получаем автора поста: здесь будет выполнен реляционный запрос
|
||
$author=$post->author;
|
||
~~~
|
||
|
||
> Info|Информация: Если для отношения не существует связанного экземпляра, то соответствующее
|
||
свойство будет null для отношений `BELONGS_TO` и `HAS_ONE` или пустым массивом
|
||
для `HAS_MANY` и `MANY_MANY`.
|
||
Стоит отметить, что отношения `HAS_MANY` и `MANY_MANY` возвращают
|
||
массивы объектов и обращаться к их свойствам необходимо в цикле, иначе
|
||
можно получить ошибку «Trying to get property of non-object».
|
||
|
||
Способ ленивой загрузки удобен , но не всегда эффективен. Например, если мы захотим
|
||
получить информацию об авторе `N` постов, использование ленивого подхода
|
||
потребует выполнения `N` запросов для объединения. В данной ситуации,
|
||
нам поможет метод «жадной загрузки» (eager loading).
|
||
|
||
Этот подход заключается в загрузке всех связанных экземпляров AR одновременно с
|
||
основным экземпляром AR. Реализуется этот подход путем использования в AR метода
|
||
[with()|CActiveRecord::with] в связке с методом [find|CActiveRecord::find] или
|
||
[findAll|CActiveRecord::findAll].
|
||
Например:
|
||
~~~
|
||
[php]
|
||
$posts=Post::model()->with('author')->findAll();
|
||
~~~
|
||
|
||
Код выше вернет массив экземпляров `Post`. В отличие от ленивого подхода, свойство `author` в каждом посте
|
||
заполнено связанным экземпляром `User` еще до обращения к свойству. Вместо выполнения объединяющего запроса
|
||
для каждого поста, жадная загрузка получает все посты вместе с авторами в одном объединяющем запросе!
|
||
|
||
В методе [with()|CActiveRecord::with] можно указать множество имен отношений и жадная загрузка вернет их за один раз.
|
||
Например, следующий код вернет посты вместе с их авторами и категориями:
|
||
|
||
~~~
|
||
[php]
|
||
$posts=Post::model()->with('author','categories')->findAll();
|
||
~~~
|
||
|
||
Кроме того, можно осуществлять вложенную жадную загрузку. Для этого вместо простого списка имен отношений, мы передаем методу
|
||
[with()|CActiveRecord::with] имена отношений, упорядоченных иерархически, как в примере ниже:
|
||
|
||
~~~
|
||
[php]
|
||
$posts=Post::model()->with(
|
||
'author.profile',
|
||
'author.posts',
|
||
'categories')->findAll();
|
||
~~~
|
||
|
||
Пример выше вернет нам все посты с их авторами и категориями, а также профиль каждого автора и все его посты.
|
||
|
||
> Note|Примечание: Порядок использования метода [with()|CActiveRecord::with] изменился, начиная с версии 1.0.2.
|
||
> Пожалуйста, читайте внимательно соответствующую документацию API.
|
||
|
||
Реализация AR в Yii очень эффективна: для жадной загрузки иерархии связанных объектов с `N` отношениями типов
|
||
`HAS_MANY` или `MANY_MANY`, потребуется только `N+1` SQL-запрос для получения требуемого результата. Это значит, что
|
||
в последнем примере потребуется 3 SQL-запроса из-за свойств `posts` и `categories`. Другие фреймворки практикуют
|
||
более радикальный подход, используя только один SQL-запрос. На первый взгляд, этот подход кажется более эффективным
|
||
вследствие меньшего количества запросов к СУБД. Однако, в действительности подход не практичен по двум причинам. Во-первых,
|
||
в результате запроса возникает множество повторных столбцов данных, которые необходимо передать и обработать. Во-вторых,
|
||
количество строк в результирующем множестве растет экспоненциально количеству задействованных таблиц, что делает этот процесс
|
||
неуправляемым с увеличением количества отношений.
|
||
|
||
Начиная с версии 1.0.2, можно принудительно выполнить реляционный запрос через один SQL-запрос. Для этого
|
||
просто добавьте вызов [together()|CActiveFinder::together] после [with()|CActiveRecord::with]. Например,
|
||
|
||
~~~
|
||
[php]
|
||
$posts=Post::model()->with(
|
||
'author.profile',
|
||
'author.posts',
|
||
'categories')->together()->findAll();
|
||
~~~
|
||
|
||
Запрос выше будет выполнен с использованием одного SQL-запроса. Без вызова
|
||
[together|CActiveFinder::together] потребуется три SQL-запроса: один связывает
|
||
таблицы `Post`, `User` и `Profile`, второй — таблицы `User` и `Post` и третий -
|
||
таблицы `Post`, `PostCategory` и `Category`.
|
||
|
||
Параметры реляционного запроса
|
||
------------------------------
|
||
|
||
Выше мы упоминали о том, что в реляционном запросе можно указать дополнительные параметры.
|
||
Эти параметры — пары имя-значение — используются для тонкой настройки реляционного запроса.
|
||
Список параметров представлен ниже.
|
||
|
||
- `select`: список выбираемых полей для связанного AR-класса. По умолчанию значение параметра равно '*', т.е. выбираются все поля таблицы.
|
||
Если поля используются в выражении (например, `COUNT(??.name) AS nameCount`),
|
||
то необходимо однозначно указывать имена полей посредством `aliasToken`;
|
||
|
||
- `condition`: соответствует оператору `WHERE`, по умолчанию значение параметра пустое. Имейте в виду, что ссылки на поля
|
||
должны быть указаны однозначно посредством `aliasToken` (например, `??.id=10`);
|
||
|
||
- `params`: параметры для связывания в генерируемом SQL-выражении. Параметры передаются как массив пар имя-значение. Параметр
|
||
доступен, начиная с версии 1.0.3;
|
||
|
||
- `on`: соответствует оператору `ON`. Условие, указываемое в этом параметре,
|
||
будет добавлено к условию объединения с использованием оператора `AND`. Имейте
|
||
в виду, что ссылки на поля должны быть указаны однозначно посредством `aliasToken` (например, `??.id=10`). Данный параметр
|
||
неприменим для отношений типа `MANY_MANY`. Параметр доступен, начиная с версии 1.0.2;
|
||
|
||
- `order`: соответствует оператору `ORDER BY`, по умолчанию значение параметра пустое. Имейте в виду, что ссылки на поля
|
||
должны быть указаны однозначно посредством `aliasToken` (например, `??.age DESC`);
|
||
|
||
- `with`: список дочерних связанных объектов, которые должны быть загружены с самим объектом.
|
||
Неправильное использование данной возможности может привести к бесконечному циклу.
|
||
|
||
- `joinType`: тип объединения для отношения. По умолчанию значение параметра равно `LEFT
|
||
OUTER JOIN`;
|
||
|
||
- `aliasToken`: маркер префикса поля. Заменяется на соответствующий псевдоним таблицы для однозначного обозначения ссылок на поля.
|
||
По умолчанию значение параметра равно `'??.'`;
|
||
|
||
- `alias`: псевдоним таблицы, ассоциированной с отношением. Этот параметр доступен с версии 1.0.1. По умолчанию значение параметра
|
||
равняется null, что означает автоматическую генерацию псевдонима таблицы. Это отличает параметр от `aliasToken`, поскольку параметр
|
||
`aliasToken` является просто маркером, который заменяется на фактический псевдоним таблицы;
|
||
|
||
- `together`: параметр, устанавливающий необходимость принудительного объединения таблицы, ассоциированной с этим отношением,
|
||
с основной таблицей. Этот параметр имеет смысл только для отношений типов `HAS_MANY` и `MANY_MANY`. Если параметр не установлен или
|
||
равен false, тогда каждое отношение `HAS_MANY` или `MANY_MANY` будет иметь собственное выражение JOIN для улучшения
|
||
производительности. Параметр доступен, начиная с версии 1.0.3;
|
||
|
||
- `group`: соответствует оператору `GROUP BY`, по умолчанию значение параметра пустое. Имейте в виду, что ссылки на поля
|
||
должны быть указаны однозначно посредством `aliasToken` (например, `??.age DESC`);
|
||
|
||
- `having`: соответствует оператору `HAVING`, по умолчанию значение параметра пустое. Имейте в виду, что ссылки на поля
|
||
должны быть указаны однозначно посредством `aliasToken` (например, `??.age DESC`). Параметр доступен, начиная с версии 1.0.1.
|
||
|
||
- `index`: имя столбца, значения которого должны быть использованы в
|
||
качестве ключей массива, хранящего связанные объекты. Без установки этого
|
||
параметра, массив связанных объектов использует целочисленный индекс,
|
||
начинающийся с нуля. Параметр может быть установлен только для отношений
|
||
`HAS_MANY` и `MANY_MANY`. Параметр доступен с версии 1.0.7.
|
||
|
||
Кроме того, для отложенной загрузки некоторых типов отношений доступен ряд дополнительных параметров:
|
||
|
||
- `limit`: параметр для ограничения количества строк в выборке. Параметр не применим для отношений `BELONGS_TO`;
|
||
|
||
- `offset`: параметр для указания начальной строки выборки. Параметр не применим для отношений `BELONGS_TO`.
|
||
|
||
Ниже мы изменим определение отношения в модели `User`, добавив несколько вышеприведенных параметров:
|
||
|
||
~~~
|
||
[php]
|
||
class User extends CActiveRecord
|
||
{
|
||
public function relations()
|
||
{
|
||
return array(
|
||
'posts'=>array(self::HAS_MANY, 'Post', 'authorID',
|
||
'order'=>'??.createTime DESC',
|
||
'with'=>'categories'),
|
||
'profile'=>array(self::HAS_ONE, 'Profile', 'ownerID'),
|
||
);
|
||
}
|
||
}
|
||
~~~
|
||
|
||
Теперь, если мы обратимся к `$author->posts`, то получим все посты автора, упорядоченные по времени создания по убыванию.
|
||
Также каждый экземпляр поста содержит свои уже подгруженные категории.
|
||
|
||
> Info|Информация: Когда поле с одинаковым именем присутствует в нескольких объединяемых таблицах, их
|
||
необходимо указать однозначно. Делается это с помощью добавления к имени поля префикса — имени таблицы.
|
||
Например, `id` станет `Team.id`. В реляционных запросах AR сделать так просто не получится, т.к.
|
||
SQL-выражения генерируются AR автоматически с выдачей псевдонима для каждой таблицы. Поэтому
|
||
во избежание конфликта имен полей, мы используем маркер для полей, имена которых необходимо
|
||
указать однозначно, а AR самостоятельно заменит маркер на подходящий псевдоним таблицы.
|
||
|
||
Динамические параметры реляционного запроса
|
||
--------------------------------
|
||
|
||
Начиная с версии 1.0.2, мы можем использовать динамические параметры как для параметра
|
||
[with()|CActiveRecord::with], так и для параметра `with`. Динамические параметры переопределяют существующие
|
||
параметры в соответствии с описанием метода [relations()|CActiveRecord::relations]. К примеру, если для модели `User`, приведенной выше,
|
||
мы хотим воспользоваться жадной загрузкой для получения постов автора в порядке возрастания (параметр `order` в определении отношения
|
||
задает убывающий порядок), можно сделать это следующим образом:
|
||
|
||
~~~
|
||
[php]
|
||
User::model()->with(array(
|
||
'posts'=>array('order'=>'??.createTime ASC'),
|
||
'profile',
|
||
))->findAll();
|
||
~~~
|
||
|
||
Начиная с версии 1.0.5 динамические параметры в реляционных запросах можно использовать вместе с
|
||
отложенной загрузкой. Для этого необходимо вызвать метод с тем же именем, что и
|
||
имя связи, и передать параметры как его аргумент. К примеру, следующий код
|
||
вернёт публикации пользователя, у которых `status` равен 1:
|
||
|
||
~~~
|
||
[php]
|
||
$user=User::model()->findByPk(1);
|
||
$posts=$user->posts(array('condition'=>'status=1'));
|
||
~~~
|
||
|
||
Статистический запрос
|
||
-----------------
|
||
|
||
> Note|Примечание: статистические запросы доступны, начиная с версии 1.0.4.
|
||
|
||
Помимо реляционных запросов, описанных выше, Yii также поддерживает так называемые статистические запросы (или запросы агрегирования).
|
||
Этот тип запросов используется для получения агрегированных данных, относящихся к связанным объектам, например количество комментариев
|
||
к каждому посту, средний рейтинг для каждого наименования продукции и т.д.
|
||
Статистические запросы могут быть использованы только для объектов, связанных отношениями `HAS_MANY` (например, у поста есть много
|
||
комментариев) или `MANY_MANY` (например, пост принадлежит многим категориям, а к категории относится множество постов).
|
||
|
||
Выполнение статистического запроса аналогично выполнению реляционного запроса в соответствии с описанием выше. Первым делом необходимо
|
||
объявить статистический запрос в методе [relations()|CActiveRecord::relations] класса [CActiveRecord].
|
||
|
||
~~~
|
||
[php]
|
||
class Post extends CActiveRecord
|
||
{
|
||
public function relations()
|
||
{
|
||
return array(
|
||
'commentCount'=>array(self::STAT, 'Comment', 'postID'),
|
||
'categoryCount'=>array(self::STAT, 'Category', 'PostCategory(postID, categoryID)'),
|
||
);
|
||
}
|
||
}
|
||
~~~
|
||
|
||
Выше мы объявили два статистических запроса: `commentCount` подсчитывает количество комментариев к посту, а `categoryCount`
|
||
считает количество категорий, к которым относится пост. Обратите внимание, что отношение между `Post` и `Comment` — типа `HAS_MANY`, а
|
||
отношение между `Post` и `Category` — типа `MANY_MANY` (с использованием преобразующей таблицы `PostCategory`). Как можно видеть,
|
||
порядок объявления очень схож с объявлением отношений, описанных выше. Единственное различие состоит в том, что в данном случае тип отношения
|
||
равен `STAT`.
|
||
|
||
За счет объявленных отношений мы можем получить количество комментариев для поста, используя выражение `$post->commentCount`.
|
||
В момент первого обращения к данному свойству для получения соответствующего результата неявным образом выполняется SQL-выражение.
|
||
Как мы уже говорили, это называется подходом *ленивой загрузки*. Можно также использовать *жадный* вариант загрузки, если необходимо
|
||
получить количество комментариев к нескольким постам:
|
||
|
||
~~~
|
||
[php]
|
||
$posts=Post::model()->with('commentCount', 'categoryCount')->findAll();
|
||
~~~
|
||
|
||
Выражение выше выполняет три SQL-запроса для получения всех постов вместе с значениями количества комментариев к ним и количества категорий.
|
||
В случае ленивой загрузки нам бы понадобилось выполнить `2*N+1` SQL-запросов для `N` постов.
|
||
|
||
По умолчанию статистический запрос считает количество с использованием выражения `COUNT`.
|
||
Его можно уточнить путем указания дополнительных параметров в момент объявления в методе [relations()|CActiveRecord::relations].
|
||
Доступные параметры перечислены ниже:
|
||
|
||
- `select`: статистическое выражение, по умолчанию равно `COUNT(*)`, что соответствует количеству дочерних объектов;
|
||
|
||
- `defaultValue`: значение, которое присваивается в случае, если результат статистического запроса для записи отрицателен.
|
||
Например, если пост не имеет ни одного комментария, то свойству `commentCount` будет присвоено это значение. По умолчанию значение
|
||
данного параметра равно 0;
|
||
|
||
- `condition`: соответствует оператору `WHERE`, по умолчанию значение параметра пустое;
|
||
|
||
- `params`: параметры для связывания в генерируемом SQL-выражении. Параметры передаются как массив пар имя-значение;
|
||
|
||
- `order`: соответствует оператору `ORDER BY`, по умолчанию значение параметра пустое;
|
||
|
||
- `group`: соответствует оператору `GROUP BY`, по умолчанию значение параметра пустое;
|
||
|
||
- `having`: соответствует оператору `HAVING`, по умолчанию значение параметра пустое.
|
||
|
||
Реляционные запросы с именованными группами условий
|
||
---------------------------------------------------
|
||
|
||
> Note|Примечание: Группы условий поддерживаются, начиная с версии 1.0.5.
|
||
|
||
В реляционном запросе [именованные группы условий](/doc/guide/database.ar#named-scopes)
|
||
могут быть использованы двумя способами. Их можно применить к основной модели и
|
||
к связанным моделям.
|
||
|
||
Следущий код показывает случай с основной моделью:
|
||
|
||
~~~
|
||
[php]
|
||
$posts=Post::model()->published()->recently()->with('comments')->findAll();
|
||
~~~
|
||
|
||
Данный код очень похож на нереляционные запросы. Единственное отличие в том, что
|
||
у нас присутствует вызов `with()` после вызовов групп условий. Данный запрос
|
||
вернёт недавно опубликованные записи вместе с комментариями к ним.
|
||
|
||
В следующем примере показано, как применить группы условий к связанным моделям:
|
||
|
||
~~~
|
||
[php]
|
||
$posts=Post::model()->with('comments:recently:approved')->findAll();
|
||
~~~
|
||
|
||
Этот запрос вернёт все записи вместе с одобренными комментариями. Здесь `comments`
|
||
относится к имени отношения. `recently` и `approved` — именованные группы, описанные
|
||
в модели `Comment`. Имя отношения и группы параметров разделяются двоеточием.
|
||
|
||
Именованные группы могут быть использованы при описании отношений модели в
|
||
методе [CActiveRecord::relations()] в параметре `with`. В следующем примере
|
||
при обращении к `$user->posts` вместе с публикациями будут получены все
|
||
*одобренные* комментарии.
|
||
|
||
~~~
|
||
[php]
|
||
class User extends CActiveRecord
|
||
{
|
||
public function relations()
|
||
{
|
||
return array(
|
||
'posts'=>array(self::HAS_MANY, 'Post', 'authorID',
|
||
'with'=>'comments:approved'),
|
||
);
|
||
}
|
||
}
|
||
~~~
|
||
|
||
> Note|Информация: Именованные группы параметров, применяемые к реляционным моделям,
|
||
должны описываться в методе [CActiveRecord::scopes], поэтому они не могут быть
|
||
параметризованы.
|
||
|
||
<div class="revision">$Id: database.arr.txt 1248 2009-07-15 19:40:44Z qiang.xue $</div>
|