поведение отношения не содержит определения для october cms
Связи
Введение
Важно: Очень часто связи используются вместе с формами.
Настройка
Рассмотрим модель Invoice:
Вы можете использовать следующие параметры для настройки связи:
Отображение менеджера связей зависит от типа отношений. Каждый тип имеет свои требования к конфигурации, которые выделены жирным шрифтом. Доступны следующие типы связей:
Has many
Например, если запись в блоге имеет много комментариев, то в качестве главной модели устанавливается запись, и отображается список комментариев, используя колонки из списка. При нажатии на комментарий отображается всплывающая форма с полями, определенными в форме «Обновить комментарий». Комментарии могут быть созданы таким же образом. Ниже приведен пример конфигурационного файла:
Belongs to many
Например, если пользователь принадлежит к нескольким ролям, то в качестве главной модели устанавливается пользователь, и отображается список ролей, используя колонки из списка. Роли пользователя могут быть добавлены или удалены. Ниже приведен пример конфигурационного файла:
Belongs to many (with Pivot Data)
Рассмотрим предыдущий пример. Роль может иметь ограниченный срок действия. При нажатии на нее отобразится всплывающая форма, которая позволяет изменить дату окончания этого срока. Ниже приведен пример конфигурационного файла:
Note: Сводные данные (на данный момент) не поддерживаются отолежнным связыванием, таким образом родительская модель должна существовать заранее.
Belongs to
Например, если телефон принадлежит человеку, то менеджер связей отобразит форму с определенными полями. При нажатии на кнопку «Link» отобразится список людей, к которым можно привязать телефон. При нажатии на кнопку «Unlink» связь исчезнет.
Has one
Например, если человек имеет один телефонный номер, то менеджер связей отобразит форму с определенными полями. При нажатии на кнопку «Изменить» отобразится форма для редактирования. Если человек уже имеет телефон, то он обновится, иначе будет добавлен новый номер.
Менеджер связей
Целевая модель должна быть сначала инициализирована в контроллере путем вызова метода initRelation() для того, чтобы управлять отношениями на любой странице.
Note: На страницах Создания, Редактирования и Предпросмотра модель инициализируется автоматически.
Вы можете отобразить менеджер связи в режиме «только чтение», передав массив [‘readOnly’ => true] в качестве второго аргумента:
Связи базы данных
Введение
Таблицы в базе данных часто связаны между собой. Например, статья в блоге может иметь множество комментариев и быть связана с ее автором. Октябрь упрощает работу и управление такими отношениями.
Определение отношений
Отношения задаются в файле с классом модели. Пример:
Вы можете использовать конструктор запросов для работы с отношениями:
Или вы можете использовать свойства объекта:
Подробные определения отношений
Ниже приведены параметры, которые можно использовать со всеми отношениями:
Пример с использованием order и conditions:
Пример с использованием scope:
Пример с использованием count:
Типы отношений
Доступны следующие типы отношений
Один к одному
После определения отношения мы можем получить связанную запись, используя свойство модели с тем же именем. Эти свойства являются динамическими и позволяют получить к ним доступ, как если бы они были обычными атрибутами модели:
Если же в модели, для которой Вы строите отношение (в данном случае User ) ключ находится не в столбце id, то Вы можете указать его в качестве третьего аргумента:
Определение обратного отношения
Если Ваша родительская модель не использует id в качестве основного ключа, или Вы хотите присоединиться к дочерней модели через другой столбец, то передайте параметр otherKey с названием столбца:
Один ко многим
Примером отношения «один ко многим» является статья в блоге, которая имеет несколько («много») комментариев. Вы можете смоделировать это отношение следующим образом:
Теперь Вы можете получить все комментарии с помощью «динамического свойства»:
Вы также можете добавить ограничения на получаемые комментарии при помощи метода comments и необходимых условий:
Вы также можете переопределить внешний и внутренний ключ при помощи параметров key и otherKey соответственно:
Определение обратного отношения
Вы также можете переопределить внешний и внутренний ключ при помощи параметров key и otherKey соответственно:
Многие ко многим
Пример структуры таблицы в БД, которая может быть использована для связи моделей.
Теперь Вы можете получить роли пользователя при помощи «динамического свойства» roles :
Вы также можете добавить ограничения на получаемые роли при помощи метода roles и необходимых условий:
Вы также можете переопределить название таблицы, которая содержит связи:
Вы также можете переопределить внешний и внутренний ключ при помощи параметров key и otherKey соответственно:
Определение обратного отношения
Получение промежуточных столбцов таблицы
По умолчанию в такой модели будут доступны только ключи. Если ваша промежуточная таблица содержит дополнительные атрибуты, то Вы должны указать их при определении отношения:
Следующие параметры поддерживаются отношениями belongsToMany :
Множество связей через третью таблицу (Has Many Through)
Давайте теперь определим отношение для модели Country :
Полиморфические отношения
Структура таблицы
Полиморфные отношения позволяют модели быть связанной с более, чем одной моделью. Например, модель Photo может быть связана с моделям Staff (сотрудник) и Product (товар). Вы можете задать такое отношение следующим образом:
Структура модели
Давайте теперь рассмотрим описание модели, необходимое для построения этого отношения:
Чтение полиморфной связи
После определения таблицы и моделей базы данных Вы можете получить доступ к отношениям через свои модели. Например, чтобы получить доступ ко всем фотографиям для сотрудника достаточно просто использовать «динамическое свойство» photos :
Полиморфные отношения «многие ко многим»
Структура таблицы
Структура модели
Определение обратного отношения
В модели Tag Вы должны указать связь к необходимым моделям. Пример:
Получение отношения
После определения таблицы и моделей базы данных Вы можете получить доступ к отношениям через свои модели. Например, чтобы получить доступ ко всем тегам для поста, используйте «динамическое свойство» tags :
Запросы к отношениям
Поскольку все типы отношений Модели могут быть вызваны через функции, то Вы можете вызывать эти функции для получения экземпляра отношения без фактического выполнения запросов. Кроме того, все типы отношений также используют конструктор запросов, позволяя Вам накладывать ограничения, фильтровать и сортировать отношения прежде чем выполнить SQL запрос.
Например, у нас есть блог, в котором модель User связана с моделью Post :
Вы можете получить все опубликованные записи пользователя следующим образом:
Методы отношений и Динамические свойства
Динамические свойства являются «lazy loading», то есть они будут загружать данные только тогда, когда Вы хотите их получить. Также разработчики часто используют «eager loading», для получения предварительно загруженных отношений, которые, как они знают, будут доступны после загрузки модели.
Запрос на существование отношений
Вы можете ограничить свои результаты при доступе к записям модели. Например, представьте, что Вы хотите получить все сообщения в блоге, содержащие хотя бы один комментарий. Для этого вы можете передать имя отношения методу has :
Вы также можете использовать операторы сравнения:
Вы также можете использовать точечную нотацию. Например, чтобы получить все записи, у которой есть хотя бы один оцененный комментарий:
Вы также можете использовать методы whereHas и orWhereHas :
Жадная загрузка (eager loading)
Теперь загрузим все книги и их авторов:
Цикл выполнит один запрос для получения всех книг в таблице, а затем будет выполнять по одному запросу на каждую книгу для получения автора. Таким образом, если у нас 25 книг, то потребуется 26 запросов.
Теперь давайте заранее получим всех авторов при помощи методов with :
Тогда будут выполнены всего два запроса:
Жадная загрузка нескольких отношений
Иногда Вам может потребоваться жадная загрузка нескольких разных отношений за одну операцию. Для этого просто передайте дополнительные аргументы методу with :
Вложенная жадная загрузка
Используйте точечную нотацию, чтобы получить вложенные отношения. Например, давайте получим всех авторов и их контакты:
Ограничения жадной загрузки
Иногда вам может быть нужно не только загрузить отношение, но также указать условие для его загрузки:
Ленивая жадная загрузка
Можно подгрузить отношения динамически, т.е. после того как вы получили коллекцию основных объектов. Это может быть полезно тогда, когда Вам неизвестно, понадобятся ли они в дальнейшем:
Вы также можете дополнить запрос при помощи функции-замыкания:
Вставка связанных моделей
Метод Save
Если вам нужно сохранить несколько связанных моделей, вы можете использовать метод saveMany :
Save и Отношения Many To Many
При работе с отношениями «многие ко многим» метод save принимает в качестве второго аргумента массив дополнительных атрибутов промежуточной таблицы:
Метод Create
Обновление отношений «Belongs To»
Связывание моделей Many to Many
Прикрепление / Отсоединение
Вы также можете вставлять связанные модели при работе с отношениями «многие ко многим». Продолжим использовать наши модели User и Role в качестве примеров ( User может иметь несколько Role ). Вы можем легко привязать новые роли к пользователю методом attach :
Вы также можете передать массив атрибутов, которые должны быть сохранены в связующей (pivot) таблице для этого отношения:
И attach и detach могут принимать массивы ID:
Использование Sync для привязки моделей «многие ко многим»
Вы также можете использовать метод sync для привязки связанных моделей. Этот метод принимает массив ID, которые должны быть сохранены в связующей таблице. Когда операция завершится только переданные ID будут существовать в промежуточной таблице для данной модели:
Вы также можете передать дополнительные атрибуты в промежуточную таблицу:
Обновление времени
Теперь при обновлении Comment владелец Post также обновит своё поле updated_at :
Отложенное связывание
Отложенное связывание позволяет отложить привязку отношений до тех пор, пока основная запись не зафиксирует изменения. Это особенно полезно, если Вам нужно подготовить некоторые модели (например, загрузку файлов) и связать их с другой моделью, которая еще не существует.
Вы можете отложить любое количество связываний при помощи session key. Когда основная запись сохраняется вместе с ключом сеанса, отношения обновляются автоматически. Отложенное связывание поддерживается автоматически в административной части сайта в формах, но Вы можете использовать эту функцию и в других местах.
Генерация session key
Используйте PHP функцию uniqid() для генерации session key:
Отложить связывания отношений
Комментарий в следующем примере не будет добавлен к статье, пока статья не будет сохранена.
Отложить разрыв связей
Комментарий в следующем примере не будет удален, если сообщение не будет сохранено.
Список всех связей
Отмена всех связей
Зафиксировать все связи
Используйте такой же подход с методом create() :
Ленивая фиксация связей
Очистка осиротевших привязок
Уничтожает все привязки старше 1 дня, которые не были зафиксированы:
Примечание: Октябрь автоматически уничтожает отложенные связывания, которые старше 5 дней. Это происходит, когда пользователь заходит в административную часть сайта.
Поведение отношения не содержит определения для october cms
Database tables are often related to one another. For example, a blog post may have many comments, or an order could be related to the user who placed it. October makes managing and working with these relationships easy and supports several different types of relationships.
Defining Relationships
Model relationships are defined as properties on your model classes. An example of defining relationships:
Relationships like models themselves, also serve as powerful query builders, accessing relationships as functions provides powerful method chaining and querying capabilities. For example:
Accessing a relationship as a property is also possible:
Detailed Definitions
Each definition can be an array where the key is the relation name and the value is a detail array. The detail array’s first value is always the related model class name and all other values are parameters that must have a key name.
The following are parameters that can be used with all relations:
Example filter using order and conditions:
Example filter using scope:
Relationship Types
The following relations types are available:
One To One
Once the relationship is defined, we may retrieve the related record using the model property of the same name. These properties are dynamic and allow you to access them as if they were regular attributes on the model:
The model assumes the foreign key of the relationship based on the model name. In this case, the Phone model is automatically assumed to have a user_id foreign key. If you wish to override this convention, you may pass the key parameter to the definition:
Defining the inverse of the relation
If your parent model does not use id as its primary key, or you wish to join the child model to a different column, you may pass the otherKey parameter to the definition specifying your parent table’s custom key:
Default models
To populate the default model with attributes, you may pass an array to the default parameter.
One To Many
Once the relationship has been defined, we can access the collection of comments by accessing the comments property. Remember, since the model provides «dynamic properties», we can access relationships as if they were defined as properties on the model:
Of course, since all relationships also serve as query builders, you can add further constraints to which comments are retrieved by calling the comments method and continuing to chain conditions onto the query:
Like the hasOne relation, you may also override the foreign and local keys by passing the key and otherKey parameters on the definition respectively:
Defining the inverse of the relation
Once the relationship has been defined, we can retrieve the Post model for a Comment by accessing the post «dynamic property»:
If your parent model does not use id as its primary key, or you wish to join the child model to a different column, you may pass the otherKey parameter to the definition specifying your parent table’s custom key:
Many To Many
Below is an example that shows the database table structure used to create the join table.
Once the relationship is defined, you may access the user’s roles using the roles dynamic property:
Of course, like all other relationship types, you may call the roles method to continue chaining query constraints onto the relationship:
As mentioned previously, to determine the table name of the relationship’s joining table, the model will join the two related model names in alphabetical order. However, you are free to override this convention. You may do so by passing the table parameter to the belongsToMany definition:
In addition to customizing the name of the joining table, you may also customize the column names of the keys on the table by passing additional parameters to the belongsToMany definition. The key parameter is the foreign key name of the model on which you are defining the relationship, while the otherKey parameter is the foreign key name of the model that you are joining to:
Defining the inverse of the relationship
Retrieving intermediate table columns
As you have already learned, working with many-to-many relations requires the presence of an intermediate join table. Models provide some very helpful ways of interacting with this table. For example, let’s assume our User object has many Role objects that it is related to. After accessing this relationship, we may access the intermediate table using the pivot attribute on the models:
Notice that each Role model we retrieve is automatically assigned a pivot attribute. This attribute contains a model representing the intermediate table, and may be used like any other model.
By default, only the model keys will be present on the pivot object. If your pivot table contains extra attributes, you must specify them when defining the relationship:
If you want your pivot table to have automatically maintained created_at and updated_at timestamps, use the timestamps parameter on the relationship definition:
If you would like to define a custom model to represent the intermediate table of your relationship, you may use pivotModel attribute when defining the relationship. Custom many-to-many pivot models should extend the October\Rain\Database\Pivot class while custom polymorphic many-to-many pivot models should extend the October\Rain\Database\MorphPivot class.
These are the parameters supported for belongsToMany relations:
Has Many Through
The has-many-through relationship provides a convenient short-cut for accessing distant relations via an intermediate relation. For example, a Country model might have many Post models through an intermediate User model. In this example, you could easily gather all blog posts for a given country. Let’s look at the tables required to define this relationship:
Now that we have examined the table structure for the relationship, let’s define it on the Country model:
Has One Through
The has-one-through relationship links models through a single intermediate relation. For example, if each supplier has one user, and each user is associated with one user history record, then the supplier model may access the user’s history through the user. Let’s look at the database tables necessary to define this relationship:
Though the history table does not contain a supplier_id column, the hasOneThrough relation can provide access to the user’s history to the supplier model. Now that we have examined the table structure for the relationship, let’s define it on the Supplier model:
Polymorphic relations
Polymorphic relations allow a model to belong to more than one other model on a single association.
One To One
Table structure
A one-to-one polymorphic relation is similar to a simple one-to-one relation; however, the target model can belong to more than one type of model on a single association. For example, imagine you want to store photos for your staff members and for your products. Using polymorphic relationships, you can use a single photos table for both of these scenarios. First, let’s examine the table structure required to build this relationship:
Two important columns to note are the imageable_id and imageable_type columns on the photos table. The imageable_id column will contain the ID value of the owning staff or product, while the imageable_type column will contain the class name of the owning model. The imageable_type column is how the ORM determines which «type» of owning model to return when accessing the imageable relation.
Model structure
Next, let’s examine the model definitions needed to build this relationship:
Retrieving Polymorphic relations
Once your database table and models are defined, you may access the relationships via your models. For example, to access the photo for a staff member, we can simply use the photo dynamic property:
You may also retrieve the owner of a polymorphic relation from the polymorphic model by accessing the name of the morphTo relationship. In our case, that is the imageable definition on the Photo model. So, we will access it as a dynamic property:
The imageable relation on the Photo model will return either a Staff or Product instance, depending on which type of model owns the photo.
One To Many
Table Structure
A one-to-many polymorphic relation is similar to a simple one-to-many relation; however, the target model can belong to more than one type of model on a single association. For example, imagine users of your application can «comment» on both posts and videos. Using polymorphic relationships, you may use a single comments table for both of these scenarios. First, let’s examine the table structure required to build this relationship:
Model Structure
Next, let’s examine the model definitions needed to build this relationship:
Retrieving The Relationship
Once your database table and models are defined, you may access the relationships via your models. For example, to access all of the comments for a post, we can use the comments dynamic property:
You may also retrieve the owner of a polymorphic relation from the polymorphic model by accessing the name of the morphTo relationship. In our case, that is the commentable definition on the Comment model. So, we will access it as a dynamic property:
The commentable relation on the Comment model will return either a Post or Video instance, depending on which type of model owns the comment.
Many To Many
Table structure
In addition to «one-to-one» and «one-to-many» relations, you may also define «many-to-many» polymorphic relations. For example, a blog Post and Video model could share a polymorphic relation to a Tag model. Using a many-to-many polymorphic relation allows you to have a single list of unique tags that are shared across blog posts and videos. First, let’s examine the table structure:
Model structure
Defining the inverse of the relationship
Next, on the Tag model, you should define a relation for each of its related models. So, for this example, we will define a posts relation and a videos relation:
Retrieving the relationship
Once your database table and models are defined, you may access the relationships via your models. For example, to access all of the tags for a post, you can simply use the tags dynamic property:
Custom Polymorphic types
Using a custom polymorphic type lets you decouple your database from your application’s internal structure. You may define a relationship «morph map» to provide a custom name for each model instead of the class name:
The most common place to register the morphMap in the boot method of a Plugin registration file.
Querying relations
Since all types of Model relationships can be called via functions, you may call those functions to obtain an instance of the relationship without actually executing the relationship queries. In addition, all types of relationships also serve as query builders, allowing you to continue to chain constraints onto the relationship query before finally executing the SQL against your database.
For example, imagine a blog system in which a User model has many associated Post models:
Access via Relationship Method
You may query the posts relationship and add additional constraints to the relationship using the posts method. This gives you the ability to chain any of the query builder methods on the relationship.
Access via Dynamic Property
Dynamic properties are «lazy loading», meaning they will only load their relationship data when you actually access them. Because of this, developers often use eager loading to pre-load relationships they know will be accessed after loading the model. Eager loading provides a significant reduction in SQL queries that must be executed to load a model’s relations.
Querying Relationship Existence
When accessing the records for a model, you may wish to limit your results based on the existence of a relationship. For example, imagine you want to retrieve all blog posts that have at least one comment. To do so, you may pass the name of the relationship to the has method:
You may also specify an operator and count to further customize the query:
Nested has statements may also be constructed using «dot» notation. For example, you may retrieve all posts that have at least one comment and vote:
If you need even more power, you may use the whereHas and orWhereHas methods to put «where» conditions on your has queries. These methods allow you to add customized constraints to a relationship constraint, such as checking the content of a comment:
Counting Related Records
In some scenarios you may want to count the number of related records found in a given relationship definition. The withCount method can be used to include a
The withCount method supports multiple relations along with additional query constraints.
You may lazy load the count column with the loadCount method.
Additional query constraints are also supported.
Eager Loading
When accessing relationships as properties, the relationship data is «lazy loaded». This means the relationship data is not actually loaded until you first access the property. However, models can «eager load» relationships at the time you query the parent model. Eager loading alleviates the N + 1 query problem. To illustrate the N + 1 query problem, consider a Book model that is related to Author :
Now let’s retrieve all books and their authors:
This loop will execute 1 query to retrieve all of the books on the table, then another query for each book to retrieve the author. So, if we have 25 books, this loop would run 26 queries: 1 for the original book, and 25 additional queries to retrieve the author of each book.
Thankfully we can use eager loading to reduce this operation to just 2 queries. When querying, you may specify which relationships should be eager loaded using the with method:
For this operation only two queries will be executed:
Eager loading multiple relationships
Sometimes you may need to eager load several different relationships in a single operation. To do so, just pass additional arguments to the with method:
Nested eager loading
To eager load nested relationships, you may use «dot» syntax. For example, let’s eager load all of the book’s authors and all of the author’s personal contacts in one statement:
Constraining Eager Loads
Sometimes you may wish to eager load a relationship, but also specify additional query constraints for the eager loading query. Here’s an example:
Lazy Eager Loading
Sometimes you may need to eager load a relationship after the parent model has already been retrieved. For example, this may be useful if you need to dynamically decide whether to load related models:
If you need to set additional query constraints on the eager loading query, you may pass a Closure to the load method:
Inserting Related Models
Insert via Relationship Method
October provides convenient methods for adding new models to relationships. Primarily models can be added to a relationship or removed from a relationship. In each case the relationship is associated or disassociated respectively.
Add method
Use the add method to associate a new relationship.
Notice that we did not access the comments relationship as a dynamic property. Instead, we called the comments method to obtain an instance of the relationship. The add method will automatically add the appropriate post_id value to the new Comment model.
If you need to save multiple related models, you may use the addMany method:
Remove method
Comparatively, the remove method can be used to disassociate a relationship, making it an orphaned record.
In the case of many-to-many relations, the record is removed from the relationship’s collection instead.
In the case of a «belongs to» relationship, you may use the dissociate method, which doesn’t require the related model passed to it.
Adding with pivot data
When working with a many-to-many relationship, the add method accepts an array of additional intermediate «pivot» table attributes as its second argument as an array.
The second argument of the add method can also specify the session key used by deferred binding when passed as a string. In these cases the pivot data can be provided as the third argument instead.
Create method
While add and addMany accept a full model instance, you may also use the create method, that accepts a PHP array of attributes, creates a model, and inserts it into the database.
Before using the create method, be sure to review the documentation on attribute mass assignment as the attributes in the PHP array are restricted by the model’s «fillable» definition.
Insert via Dynamic Property
Relationships can be set directly via their properties in the same way you would access them. Setting a relationship using this approach will overwrite any relationship that existed previously. The model should be saved afterwards like you would with any attribute.
Alternatively you may set the relationship using the primary key, this is useful when working with HTML forms.
Relationships can be disassociated by assigning the NULL value to the property.
Many To Many Relations
Attaching / Detaching
When working with many-to-many relationships, Models provide a few additional helper methods to make working with related models more convenient. For example, let’s imagine a user can have many roles and a role can have many users. To attach a role to a user by inserting a record in the intermediate table that joins the models, use the attach method:
When attaching a relationship to a model, you may also pass an array of additional data to be inserted into the intermediate table:
Of course, sometimes it may be necessary to remove a role from a user. To remove a many-to-many relationship record, use the detach method. The detach method will remove the appropriate record out of the intermediate table; however, both models will remain in the database:
For convenience, attach and detach also accept arrays of IDs as input:
Syncing For convenience
You may also use the sync method to construct many-to-many associations. The sync method accepts an array of IDs to place on the intermediate table. Any IDs that are not in the given array will be removed from the intermediate table. So, after this operation is complete, only the IDs in the array will exist in the intermediate table:
You may also pass additional intermediate table values with the IDs:
Touching Parent Timestamps
Deferred Binding
Deferred bindings allows you to postpone model relationships binding until the master record commits the changes. This is particularly useful if you need to prepare some models (such as file uploads) and associate them to another model that doesn’t exist yet.
You can defer any number of slave models against a master model using a session key. When the master record is saved along with the session key, the relationships to slave records are updated automatically for you. Deferred bindings are supported in the back-end Form behavior automatically, but you may want to use this feature in other places.
Generating a session key
The session key is required for deferred bindings. You can think of a session key as of a transaction identifier. The same session key should be used for binding/unbinding relationships and saving the master model. You can generate the session key with PHP uniqid() function. Note that the form helper generates a hidden field containing the session key automatically.
Defer a relation binding
The comment in the next example will not be added to the post unless the post is saved.
Defer a relation unbinding
The comment in the next example will not be deleted unless the post is saved.
List all bindings
Use the withDeferred method of a relation to load all records, including deferred. The results will include existing relations as well.
Cancel all bindings
It’s a good idea to cancel deferred binding and delete the slave objects rather than leaving them as orphans.
Commit all bindings
You can commit (bind or unbind) all deferred bindings when you save the master model by providing the session key with the second argument of the save method.
The same approach works with the model’s create method:
Lazily commit bindings
Clean up orphaned bindings
Destroys all bindings that have not been committed and are older than 1 day:
Note: October CMS automatically destroys deferred bindings that are older than 5 days. It happens when a backend user logs into the system.
Disable Deferred Binding
Sometimes you might need to disable deferred binding entirely for a given model, for instance if you are loading it from a separate database connection. In order to do that, you need to make sure that the model’s sessionKey property is null before the pre and post deferred binding hooks in the internal save method are run. To do that, you can bind to the model’s model.saveInternal event.
Note: This will disable deferred binding entirely for any model’s you apply this override to.