Laravel 5.4
Awesome Laravel
- Awesome Laravel (Chirag Gude)
Prologue
- Release Notes
- Upgrade Guide
Getting Started
- Installation
- Configuration
- Directory Structure
- Laravel Homestead
- valet
Architecture Concepts
- Request Lifecycle
- Service Container
- Service Providers
- Facades
The Basics
- Routing
- Errors & Logging
- Middleware
- CSRF Protection
- Controllers
- HTTP Requests
- HTTP Responses
- Views
- HTTP Session
- Validation
Frontend
- Blade Templates
- Localization
- JavaScript & CSS Scaffolding
- Compiling Assets (Laravel Mix)
Security
- Authentication
- API Authentication (Passport)
- Authorization
- Encryption
- Hashing
- Resetting Passwords
Digging Deeper
- Artisan Console
- Queues
- Package Development
- Task Scheduling
- Broadcasting
- Cache
- Collections
- Events
- File Storage
- helpers
- Notifications
Database
- Database Getting Started
- Database Query Builder
- Database Pagination
- Database Migrations
- Database Seeding
- Redis
Eloquent ORM
- Eloquent Getting Started
- Eloquent Relationships
- Eloquent Collections
- Eloquent Mutators
- Eloquent Serialization
Testing
- Testing Getting Started
- HTTP Tests
- Browser Tests (Laravel Dusk)
- Database Testing
- Mocking
- redirect
Official Packages
- Laravel Cashier
- Envoy Task Runner
- Laravel Scout
Eloquent Relationships
Introduction
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. Eloquent makes managing and working with these relationships easy, and supports several different types of relationships:
- One To One
- One To Many
- Many To Many
- Has Many Through
- Polymorphic Relations
- Many To Many Polymorphic Relations
Defining Relationships
Eloquent relationships are defined as methods on your Eloquent model classes. Since, like Eloquent models themselves, relationships also serve as powerful query builders, defining relationships as methods provides powerful method chaining and querying capabilities. For example, we may chain additional constraints on this posts
relationship:
But, before diving too deep into using relationships, let’s learn how to define each type.
One To One
A one-to-one relationship is a very basic relation. For example, a User
model might be associated with one Phone
. To define this relationship, we place a phone
method on the User
model. The phone
method should call the hasOne
method and return its result:
The first argument passed to the hasOne
method is the name of the related model. Once the relationship is defined, we may retrieve the related record using Eloquent’s dynamic properties. Dynamic properties allow you to access relationship methods as if they were properties defined on the model:
Eloquent determines 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 a second argument to the hasOne
method:
Additionally, Eloquent assumes that the foreign key should have a value matching the id
(or the custom $primaryKey
) column of the parent. In other words, Eloquent will look for the value of the user’s id
column in the user_id
column of the Phone
record. If you would like the relationship to use a value other than id
, you may pass a third argument to the hasOne
method specifying your custom key:
Defining The Inverse Of The Relationship
So, we can access the Phone
model from our User
. Now, let’s define a relationship on the Phone
model that will let us access the User
that owns the phone. We can define the inverse of a hasOne
relationship using the belongsTo
method:
In the example above, Eloquent will try to match the user_id
from the Phone
model to an id
on the User
model. Eloquent determines the default foreign key name by examining the name of the relationship method and suffixing the method name with _id
. However, if the foreign key on the Phone
model is not user_id
, you may pass a custom key name as the second argument to the belongsTo
method:
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 a third argument to the belongsTo
method specifying your parent table’s custom key:
One To Many
A “one-to-many” relationship is used to define relationships where a single model owns any amount of other models. For example, a blog post may have an infinite number of comments. Like all other Eloquent relationships, one-to-many relationships are defined by placing a function on your Eloquent model:
Remember, Eloquent will automatically determine the proper foreign key column on the Comment
model. By convention, Eloquent will take the “snake case” name of the owning model and suffix it with _id
. So, for this example, Eloquent will assume the foreign key on the Comment
model is post_id
.
Once the relationship has been defined, we can access the collection of comments by accessing the comments
property. Remember, since Eloquent provides “dynamic properties”, we can access relationship methods 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
method, you may also override the foreign and local keys by passing additional arguments to the hasMany
method:
One To Many (Inverse)
Now that we can access all of a post’s comments, let’s define a relationship to allow a comment to access its parent post. To define the inverse of a hasMany
relationship, define a relationship function on the child model which calls the belongsTo
method:
Once the relationship has been defined, we can retrieve the Post
model for a Comment
by accessing the post
“dynamic property”:
In the example above, Eloquent will try to match the post_id
from the Comment
model to an id
on the Post
model. Eloquent determines the default foreign key name by examining the name of the relationship method and suffixing the method name with _id
. However, if the foreign key on the Comment
model is not post_id
, you may pass a custom key name as the second argument to the belongsTo
method:
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 a third argument to the belongsTo
method specifying your parent table’s custom key:
Many To Many
Many-to-many relations are slightly more complicated than hasOne
and hasMany
relationships. An example of such a relationship is a user with many roles, where the roles are also shared by other users. For example, many users may have the role of “Admin”. To define this relationship, three database tables are needed: users
, roles
, and role_user
. The role_user
table is derived from the alphabetical order of the related model names, and contains the user_id
and role_id
columns.
Many-to-many relationships are defined by writing a method that returns the result of the belongsToMany
method. For example, let’s define the roles
method on our User
model:
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, Eloquent will join the two related model names in alphabetical order. However, you are free to override this convention. You may do so by passing a second argument to the belongsToMany
method:
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 arguments to the belongsToMany
method. The third argument is the foreign key name of the model on which you are defining the relationship, while the fourth argument is the foreign key name of the model that you are joining to:
Defining The Inverse Of The Relationship
To define the inverse of a many-to-many relationship, you simply place another call to belongsToMany
on your related model. To continue our user roles example, let’s define the users
method on the Role
model:
As you can see, the relationship is defined exactly the same as its User
counterpart, with the exception of simply referencing the App\User
model. Since we’re reusing the belongsToMany
method, all of the usual table and key customization options are available when defining the inverse of many-to-many relationships.
Retrieving Intermediate Table Columns
As you have already learned, working with many-to-many relations requires the presence of an intermediate table. Eloquent provides 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 Eloquent 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 withTimestamps
method on the relationship definition:
Filtering Relationships Via Intermediate Table Columns
You can also filter the results returned by belongsToMany
using the wherePivot
and wherePivotIn
methods when defining the relationship:
Defining Custom Intermediate Table Models
If you would like to define a custom model to represent the intermediate table of your relationship, you may call the using
method when defining the relationship. All custom models used to represent intermediate tables of relationships must extend the Illuminate\Database\Eloquent\Relations\Pivot
class:
Has Many Through
The “has-many-through” relationship provides a convenient shortcut 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:
Though posts
does not contain a country_id
column, the hasManyThrough
relation provides access to a country’s posts via $country->posts
. To perform this query, Eloquent inspects the country_id
on the intermediate users
table. After finding the matching user IDs, they are used to query the posts
table.
Now that we have examined the table structure for the relationship, let’s define it on the Country
model:
The first argument passed to the hasManyThrough
method is the name of the final model we wish to access, while the second argument is the name of the intermediate model.
Typical Eloquent foreign key conventions will be used when performing the relationship’s queries. If you would like to customize the keys of the relationship, you may pass them as the third and fourth arguments to the hasManyThrough
method. The third argument is the name of the foreign key on the intermediate model, the fourth argument is the name of the foreign key on the final model, and the fifth argument is the local key:
Polymorphic Relations
Table Structure
Polymorphic relations allow a model to belong to more than one other model on a single association. For example, imagine users of your application can “comment” both posts and videos. Using polymorphic relationships, you can use a single comments
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 commentable_id
and commentable_type
columns on the comments
table. The commentable_id
column will contain the ID value of the post or video, while the commentable_type
column will contain the class name of the owning model. The commentable_type
column is how the ORM determines which “type” of owning model to return when accessing the commentable
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 all of the comments for a post, we can simply 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 method that performs the call to morphTo
. In our case, that is the commentable
method on the Comment
model. So, we will access that method 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.
Custom Polymorphic Types
By default, Laravel will use the fully qualified class name to store the type of the related model. For instance, given the example above where a Comment
may belong to a Post
or a Video
, the default commentable_type
would be either App\Post
or App\Video
, respectively. However, you may wish to decouple your database from your application’s internal structure. In that case, you may define a relationship “morph map” to instruct Eloquent to use a custom name for each model instead of the class name:
You may register the morphMap
in the boot
function of your AppServiceProvider
or create a separate service provider if you wish.
Many To Many Polymorphic Relations
Table Structure
In addition to traditional polymorphic 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
Next, we’re ready to define the relationships on the model. The Post
and Video
models will both have a tags
method that calls the morphToMany
method on the base Eloquent class:
Defining The Inverse Of The Relationship
Next, on the Tag
model, you should define a method for each of its related models. So, for this example, we will define a posts
method and a videos
method:
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:
You may also retrieve the owner of a polymorphic relation from the polymorphic model by accessing the name of the method that performs the call to morphedByMany
. In our case, that is the posts
or videos
methods on the Tag
model. So, you will access those methods as dynamic properties:
Querying Relations
Since all types of Eloquent relationships are defined via methods, you may call those methods to obtain an instance of the relationship without actually executing the relationship queries. In addition, all types of Eloquent 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:
You may query the posts
relationship and add additional constraints to the relationship like so:
You are able to use any of the query builder methods on the relationship, so be sure to explore the query builder documentation to learn about all of the methods that are available to you.
Relationship Methods Vs. Dynamic Properties
If you do not need to add additional constraints to an Eloquent relationship query, you may simply access the relationship as if it were a property. For example, continuing to use our User
and Post
example models, we may access all of a user’s posts like so:
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:
Querying Relationship Absence
When accessing the records for a model, you may wish to limit your results based on the absence of a relationship. For example, imagine you want to retrieve all blog posts that don’t have any comments. To do so, you may pass the name of the relationship to the doesntHave
method:
If you need even more power, you may use the whereDoesntHave
method to put “where” conditions on your doesntHave
queries. This method allows you to add customized constraints to a relationship constraint, such as checking the content of a comment:
Counting Related Models
If you want to count the number of results from a relationship without actually loading them you may use the withCount
method, which will place a {relation}_count
column on your resulting models. For example:
You may add the “counts” for multiple relations as well as add constraints to the queries:
You may also alias the relationship count result, allowing multiple counts on the same relationship:
Eager Loading
When accessing Eloquent 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, Eloquent 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 Eloquent 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:
In this example, Eloquent will only eager load posts where the post’s title
column contains the word first
. Of course, you may call other query builder methods to further customize the eager loading operation:
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 an array keyed by the relationships you wish to load. The array values should be Closure
instances which receive the query instance:
Inserting & Updating Related Models
The Save Method
Eloquent provides convenient methods for adding new models to relationships. For example, perhaps you need to insert a new Comment
for a Post
model. Instead of manually setting the post_id
attribute on the Comment
, you may insert the Comment
directly from the relationship’s save
method:
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 save
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 saveMany
method:
The Create Method
In addition to the save
and saveMany
methods, you may also use the create
method, which accepts an array of attributes, creates a model, and inserts it into the database. Again, the difference between save
and create
is that save
accepts a full Eloquent model instance while create
accepts a plain PHP array
:
Before using the create
method, be sure to review the documentation on attribute mass assignment.
Belongs To Relationships
When updating a belongsTo
relationship, you may use the associate
method. This method will set the foreign key on the child model:
When removing a belongsTo
relationship, you may use the dissociate
method. This method will set the relationship’s foreign key to null
:
Many To Many Relationships
Attaching / Detaching
Eloquent also provides 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 Associations
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 given array will exist in the intermediate table:
You may also pass additional intermediate table values with the IDs:
If you do not want to detach existing IDs, you may use the syncWithoutDetaching
method:
Toggling Associations
The many-to-many relationship also provides a toggle
method which “toggles” the attachment status of the given IDs. If the given ID is currently attached, it will be detached. Likewise, if it is currently detached, it will be attached:
Saving Additional Data On A Pivot Table
When working with a many-to-many relationship, the save
method accepts an array of additional intermediate table attributes as its second argument:
Updating A Record On A Pivot Table
If you need to update an existing row in your pivot table, you may use updateExistingPivot
method. This method accepts the pivot record foreign key and an array of attributes to update:
Touching Parent Timestamps
When a model belongsTo
or belongsToMany
another model, such as a Comment
which belongs to a Post
, it is sometimes helpful to update the parent’s timestamp when the child model is updated. For example, when a Comment
model is updated, you may want to automatically “touch” the updated_at
timestamp of the owning Post
. Eloquent makes it easy. Just add a touches
property containing the names of the relationships to the child model:
Now, when you update a Comment
, the owning Post
will have its updated_at
column updated as well, making it more convenient to know when to invalidate a cache of the Post
model: