On the Pinco.de blog there's a post that covers the use of pivot models for role management in SaaS applications. The tutorial shows how to use the Laravel Eloquent "withPivot" method and a pivot database table to create an easy to use relationship between "users" and "teams" in a PHP application.

If you have ever developed any kind of SaaS app (like Spark), you know what team level role management means. Instead of picking a bad strategy for handling roles, we can bring simple solution by using Pivot Models.

The tutorial starts by talking about "robust permission handling" and why, more often than not, a simpler role-based approach is enough. It then covers the pivot table itself, showing the code to create the table. Next comes the creation of the relationship between teams and users via the withPivot method. With the relationship in place, the article then covers attaching users to a team, generating the models and how to add permission evaluation into the model's functionality.

Yesterday Taylor Otwell released Laravel 5.6 right before the Laracon Online conference. We had a little conference party here in Vienna and a great time watching all the talks together. In one of them Taylor walked us through the new Laravel features and I want to point out my top 3 of them.

For each of his top three he provides some code examples and screenshots where appropriate:

In a post to his site Christoph Rumpel shows the Laravel (well, Eloquent) users out there how to use groupBy at multiple levels for customizing and sorting the results of your database queries.

Since Laravel v5.5.29 you can group collections by multiple levels. Let's see what this means and how this works.

The post starts with some of the current functionality, showing how the groupBy could be used before with a simple collection to group student data by skill level. It then gets into the new functionality, modifying the example to group by both the skill level and by the "teacher" value. The result is a sorted set of results where the top level is the skill level and, inside of each, the teachers with students under that. The post finishes by "going crazy" and showing the grouping by event more criteria, adding "name" and "email" columns to the list.

On the Pineco.de blog there's a new post for the Laravel users out there showing you a simple way to integrate translations handling into your models. This functionality allows you to more easily build multilingual applications without having some of the overhead of a separate translation framework.

Making you models translatable could be an issue, especially if you are running an application that is multilingual. For static texts, we can use the built-in translation engine, but for models, we need to solve a more complex issue. Let’s take a look at a simple yet flexible solution.

While the post starts with a recommendation to use a full package if you need a more robust system, it quickly moves into the simpler structure they'll be defining. The tutorial describes the "translation mechanism" from a high level and includes the code to create the database table for holding the translated content. With that in place, next up is the model to connect the application with the table and a trait to house the translation logic. This is then used directly in the template (as a translation property) to fetch the translated version of the content.

When starting out with Eloquent, it’s natural to reach for familiar operations like where and join. For more advanced users, features like scopes, accessors, and mutators offer more expressive alternatives to the query-building patterns of old.

Let’s explore another alternative that can be used as a stand-in for repetitive where statements and local scopes. This technique involves creating new Eloquent models that extend other models. By extending another model, you inherit the full functionality of the parent model, while retaining the ability to add custom methods, scopes, event listeners, etc. This is commonly referred to as “Single Table Inheritance,” but I prefer to just call it “Model Inheritance”.

He starts with an example using the User model and creating a "local scope" method to answer the "is admin?" question. He then abstracts this out even more with an Admin model that extends the User that can be used instead to refer to admin users only. He includes examples of this in use for notifications, guard classes and model factories. He ends the post with one "gotcha" to this method - the fact that relationships no longer work on the Admin model - and how to work around it.

In a new post to his site Amit Merchant covers the difference between two functions in Laravel's Eloquent functionality that do similar things: load() versus with() for eager loading.

Today, while working with one of my projects(which is built on top Laravel) I bumped into the situation where I needed to get associated model’s data for one of the models. So here, I had two approaches in Laravel to accomplish this which are basically called Eager Loading: with() [and] load().

Both accomplish the same end results - eager loading a related model onto the first. In fact, they both run exactly the same two queries. The key difference is that with() eager loads the related model up front, immediately after the initial query (all(), first(), or find(x), for example); when using load(), you run the initial query first, and then eager load the relation at some later point.

He then goes through examples of each and the queries they produce on the backend. He shows how splitting up the queries might be a better option for some cases and finishes with the benefits of using each (use cases).

On the Laravel News site they've posted a tutorial sharing some of the basics around the optimizing Eloquent queries with the help of its own "eager loading" feature.

Object Relational mapping (ORM) makes working with databases amazingly simple. While defining database relationships in an object-oriented way makes it easy to query related model data, developers might not pay attention to the underlying database calls.

A standard database optimization for an ORM is eager-loading related data. We will set up some example relationships and then walk through how queries change with and without eager loading. I like to get my hands directly on code and experiment with things, and I hope to illustrate how eager loading works with some examples will further help you understand how to optimize your queries.

They start with a classic example of the "N+1 problem" when working with database records and how, without you knowing, you might be causing it with lazy loading. The article then talks about eager loading vs lazy loading and how they differ in most ORMs. It then covers Eloquent, setting up some migrations for an example blog application and creating the relationships between Author (user) and the Posts. The models are created and seeders are built to populate the tables with Faker data. Finally it gets to the use of eager loading, making use of the "with" functionality to modify the query structure behind the scenes. The post finishes with mentions of two other eager loading types - lazy eager loading and nested eager loading.

On the SitePoint PHP blog they've posted a tutorial from Christopher Vundi that looks at the relationships that are a part of the Eloquent database package in Laravel. He uses the article to re-introduce polymorphic relationships you can define between your models to make cross-entity data access easier.

You’ve probably used different types of relationships between models or database tables, like those commonly seen in Laravel: one-to-one, one-to-many, many-to-many, and has-many-through. But there’s another type of relationship that’s not so common: polymorphic. So what is a polymorphic relationship?

A polymorphic relationship is where a model can belong to more than one other model on a single association. [...] With polymorphic relationships, we don’t need two tables. Let’s look into polymorphic relationships through a practical example.

He then starts in on what he'll be making in the tutorial, a system to manage songs, albums and upvotes. He outlines the basic table structure and uses the artisan command to generate both the models and migrations for the three tables. He then runs the migration to build out the tables and starts filling in the relation methods (hasOne, belongsTo, etc) and the special "morph*" methods to define the polymorphic relationships. He includes code examples showing how to access the information from the model objects and how to create custom polymorphic types if needed.

In the most recent episode of the North Meets South podcast - Episode #28 - hosts Jacob Bennett and Michael Dyrynda talk about Laravel. More specifically they cover Eloquent functionality, client expectations, and packages.

In this episode, Jake and Michael talk about Eloquent observers and answer listener questions about managing client expectations and packages we use in our Laravel applications.