Concept Problem:
I have a very simple problem when using the touches attribute, to automatically update timestamp on a depending model; it correctly does so but also applies the global scopes.
Is there any way to turn this functionality off? Or to ask specifically for automatic touches to ignore global scopes?
Concrete Example:
When an ingredient model is updated all related recipes should be touched. This works fine, except we have a globalScope for separating the recipes based on locales, that also gets used when applying the touches.
Ingredient Model:
class Ingredient extends Model
{
protected $touches = ['recipes'];
public function recipes() {
return $this->belongsToMany(Recipe::class);
}
}
Recipe Model:
class Recipe extends Model
{
protected static function boot()
{
parent::boot();
static::addGlobalScope(new LocaleScope);
}
public function ingredients()
{
return $this->hasMany(Ingredient::class);
}
}
Locale Scope:
class LocaleScope implements Scope
{
public function apply(Builder $builder, Model $model)
{
$locale = app(Locale::class);
return $builder->where('locale', '=', $locale->getLocale());
}
}
If you want to explicitly avoid a global scope for a given query, you may use the withoutGlobalScope() method. The method accepts the class name of the global scope as its only argument.
$ingredient->withoutGlobalScope(LocaleScope::class)->touch();
$ingredient->withoutGlobalScopes()->touch();
Since you're not calling touch() directly, in your case it will require a bit more to make it work.
You specify relationships that should be touched in model $touches attribute. Relationships return query builder objects. See where I'm going?
protected $touches = ['recipes'];
public function recipes() {
return $this->belongsToMany(Recipe::class)->withoutGlobalScopes();
}
If that messes with the rest of your application, just create a new relationship specifically for touching (heh :)
protected $touches = ['recipesToTouch'];
public function recipes() {
return $this->belongsToMany(Recipe::class);
}
public function recipesToTouch() {
return $this->recipes()->withoutGlobalScopes();
}
You can define a relationship in the model and pass parameters to it like following:
public function recipes($isWithScope=true)
{
if($isWithScope)
return $this->belongsToMany(Recipe::class);
else
return $this->recipes()->withoutGlobalScopes();
}
then use it like this recipes->get(); and recipes(false)->get();
Related
I am designing an app where user can define traits/attributes for objects.
I was planning to go like this
class AttributeName extends Model
{
//
}
class Attribute extends Model
{
public function attributeName()
{
return $this->belongsTo('AttributeName');
}
public function job()
{
return $this->belongsTo('Job');
}
}
class Job extends Model
{
public function attributes()
{
return $this->hasMany('Attribute');
}
public function getAttributeValue($attributeNameId)
{
return $this->attributes->where('attribute_name_id', $attributeNameId)->first()->value ?? ;;
}
}
Unfourtunately, this gives me hard time as $this->attributes has another meaning for Laravel models. So Attribute is not a very good name for these things.
Naming it trait won't go well in PHP either. So what should I name this? Is there any common name that reflects semantics as well as attribute or trait does but doesn't conflict with other uses in Laravel and PHP?
I am attempting to clean up my code in my Laravel models at the moment and at the moment I have a lot of code duplication with local scopes in each model. Each model has a lot of similar columns that relate and I am figuring out how I can put these scopes in a single place but still be able to pass the $table variable so it can be used dynamically.
What I currently have in a few models for example
public function scopeName($query, $name)
{
return $query->where($this->table.'name', $name);
}
public function scopeStatus($query, $status)
{
return $query->where($this->table.'.status', $status);
}
I want to take these common scopes and have them in a single class where I can pass the table to it and then I can eliminate the code duplication. Haven't been able to find anything similar with extending the parent Model. I am also aware of global scopes but that still creates a similar issue where I am typing static::addGlobalScope(new StatusScope) in each model.
Any help is greatly appreciated.
Would using a trait be considered a bad option here?
Trait is better here than inheritance, read more: https://en.wikipedia.org/wiki/Composition_over_inheritance
You can create a new trait for it:
trait CommonScopesTrait
{
public function scopeName($query, $name)
{
return $query->where($this->table.'name', $name);
}
public function scopeStatus($query, $status)
{
return $query->where($this->table.'.status', $status);
}
}
And use it in your model(s):
class YourModel extends Model
{
use CommonScopesTrait;
}
In addition to the answer of lptn, there is another option, which is also quite nice.
Create a basic model which you extend to Eloquent:
class BasicScope extends Eloquent {
public function scopeName($query, $name)
{
return $query->where($this->table.'name', $name);
}
public function scopeStatus($query, $status)
{
return $query->where($this->table.'.status', $status);
}
}
And then extend your own models on the BasicScope model, so you will have those methods available:
class User extends BasicScope {
}
When I read the Laravel 5.3's source code, I find the following codes
public function withGlobalScope($identifier, $scope)
{
$this->scopes[$identifier] = $scope;
if (method_exists($scope, 'extend')) {
$scope->extend($this);
}
return $this;
}
I am confused about why it is the following codes in the method, is it used anywhere?
if (method_exists($scope, 'extend')) {
$scope->extend($this);
}
Thanks!
It's meant for extending the Builder within the context of a Scope class.
Inside a global Scope (class which extends the Scope interface), you can create an extend function next to the apply function.
This extend function is called with the Eloquent builder as parameter. Imagine some PopularUsersScope, which only gets very popular users:
public function apply(Builder $builder, Model $model): void
{
$builder->join(...)->where(...) // determine popularity
}
public function extend(Builder $builder)
{
$builder->macro('demote', function (Builder $builder) {
return $builder->update(...) // query to make user not so popular
});
}
Now lets have a model Clan, which is a group of users, some of which are popular. We have a constrained relation on Clan:
public function popular_users(): belongsToMany
{
return $this->hasMany(User::class)
->withGlobalScope('popularUsers', new PopularUsersScope)
}
Because we defined a macro within the scope extend function, we can do $user->demote() for any popular user, but not for normal users.
This might be a bit of a silly example, but it can be useful in fairly abstract use cases.
See SoftDeletingScope in the Laravel Framework code for a practical example: SoftDeletable items need some extra methods on the Builder for restoring and eager loading deleted items.
Extend in SoftDeletingScope dynamically adds multiple extensions to the Builder, from an Array $this->extensions, and registers an replacement for the default delete function on the model:
public function extend(Builder $builder)
{
foreach ($this->extensions as $extension) {
$this->{"add{$extension}"}($builder);
}
$builder->onDelete(function (Builder $builder) {
$column = $this->getDeletedAtColumn($builder);
return $builder->update([
$column => $builder->getModel()->freshTimestampString(),
]);
});
}
In Laravel 4, query scopes are available on all queries (including ones generated by relations queries). This means that for the following (example) models:
Customer.php:
<?php
class Customer extends Eloquent {
public function order() { return $this->hasMany('Order'); }
}
Order.php:
<?php
class Order extends Eloquent {
public function scopeDelivered($query) { return $query->where('delivered', '=', true); }
public function customer() { return $this->belongsTo('Customer'); }
}
Both of the following work:
var_dump(Order::delivered()->get()); // All delivered orders
var_dump(Customer::find(1)->orders()->delivered()->get()); // only orders by customer #1 that are delivered
This is useful from within a controller because the query logic for finding delivered orders doesn't have to be repeated.
Recently, though, I've been convinced that the Repository pattern is optimal for not only separation of concerns but also for the possibility of a ORM/DB switch or the necessity of adding middleware like a cache. Repositories feel very natural, because now instead of having scopes bloat my models, the associated queries are instead part of the Repository (which makes more sense because naturally this would be a method of the collection not the item).
For example,
<?php
class EloquentOrderRepository {
protected $order;
public function __construct(Order $order) { $this->order = $order; }
public function find($id) { /* ... */ }
/* etc... */
public function allDelievered() { return $this->order->where('delivered', '=', true)->get(); }
}
However, now I have the delivered scope repeated, so to avoid violating DRY, I remove it from the model (which seems logical as per the justification above). But now, I can no longer can use scopes on relations (like $customer->orders()->delivered()). The only workaround here I see is somehow instantiating the Repository with the pre-made query (similar to what is passed to the scopes in the models) in the Relation base class. But this involves changing (and overriding) a lot of code and default behavior and seems to make things more coupled than they should be.
Given this dilemma, is this is misuse of a repository? If not, is my solution the only way to regain the functionality that I would like? Or is having the scopes in the models not tight enough coupling to justify this extra code? If the scopes aren't tight coupling, then is there a way to use both the Repository pattern and scopes while still being DRY?
Note: I am aware of some similar questions on similar topics but none of them address the issue presented here with queries generated by relationships, which do not rely on the Repository.
I've managed to find a solution. It's rather hacky and I'm not sure whether I consider it acceptable (it uses a lot of things in ways that they likely weren't meant to be used). To summarize, the solution allows you to move scopes to the repository. Each repository (on instantiation) is booted once, and during this process all of the scope methods are extracted and added to each query created by the eloquent model (via macros) by way of a Illuminate\Database\Eloquent\ScopeInterface.
The (Hack-y) solution
Repository Pattern Implementation
app/lib/PhpMyCoder/Repository/Repository.php:
<?php namespace PhpMyCoder\Repository;
interface Repository {
public function all();
public function find($id);
}
app/lib/PhpMyCoder/Repository/Order/OrderRepository.php:
<?php namespace PhpMyCoder\Repository\Order;
interface OrderRepository extends PhpMyCoder\Repository\Repository {}
Adding Eloquent Repositories (and a hack)
app/lib/PhpMyCoder/Repository/Order/EloquentOrderRepository.php:
<?php namespace PhpMyCoder\Repository\Order;
use PhpMyCoder\Repository\EloquentBaseRepository;
class EloquentOrderRepository extends EloquentBaseRepository implements OrderRepository {
public function __construct(\Order $model) {
parent::__construct($model);
}
public function finished() {
return $this->model->finished()->get();
}
public function scopeFinished($query) {
return $query->where('finished', '=', true);
}
}
Notice how the repository contains the scope that would normally be stored in the Order model class. In the database (for this example), Order needs to have a boolean column finished. We'll cover the details of EloquentBaseRepository below.
app/lib/PhpMyCoder/Repository/EloquentBaseRepository.php:
<?php namespace PhpMyCoder\Repository;
use Illuminate\Database\Eloquent\Model;
abstract class EloquentBaseRepository implements Repository {
protected $model;
// Stores which repositories have already been booted
protected static $booted = array();
public function __construct(Model $model) {
$this->model = $model;
$this->bootIfNotBooted();
}
protected function bootIfNotBooted() {
// Boot once per repository class, because we only need to
// add the scopes to the model once
if(!isset(static::$booted[get_class($this)])) {
static::$booted[get_class($this)] = true;
$this->boot();
}
}
protected function boot() {
$modelScope = new ModelScope(); // covered below
$selfReflection = new \ReflectionObject($this);
foreach (get_class_methods($this) as $method) {
// Find all scope methods in the repository class
if (preg_match('/^scope(.+)$/', $method, $matches)) {
$scopeName = lcfirst($matches[1]);
// Get a closure for the scope method
$scopeMethod = $selfReflection->getMethod($method)->getClosure($this)->bindTo(null);
$modelScope->addScope($scopeName, $scopeMethod);
}
}
// Attach our special ModelScope to the Model class
call_user_func([get_class($this->model), 'addGlobalScope'], $modelScope);
}
public function __call($method, $arguments) {
// Handle calls to scopes on the repository similarly to
// how they are handled on Eloquent models
if(method_exists($this, 'scope' . ucfirst($method))) {
return call_user_func_array([$this->model, $method], $arguments)->get();
}
}
/* From PhpMyCoder\Repository\Order\OrderRepository (inherited from PhpMyCoder\Repository\Repository) */
public function all() {
return $this->model->all();
}
public function find($id) {
return $this->model->find($id);
}
}
Each time an instance of a repository class is instantiated for the first time, we boot the repository. This involves aggregating all "scope" methods on the repository into a ModelScope object and then applying that to the model. The ModelScope will apply our scopes to each query created by the model (as seen below).
app/lib/PhpMyCoder/Repository/ModelScope.php:
<?php namespace PhpMyCoder\Repository;
use Illuminate\Database\Eloquent\ScopeInterface;
use Illuminate\Database\Eloquent\Builder;
class ModelScope implements ScopeInterface {
protected $scopes = array(); // scopes we need to apply to each query
public function apply(Builder $builder) {
foreach($this->scopes as $name => $scope) {
// Add scope to the builder as a macro (hack-y)
// this mimics the behavior and return value of Builder::callScope()
$builder->macro($name, function() use($builder, $scope) {
$arguments = func_get_args();
array_unshift($arguments, $builder->getQuery());
return call_user_func_array($scope, $arguments) ?: $builder->getQuery();
});
}
}
public function remove(Builder $builder) {
// Removing is not really possible (no Builder::removeMacro),
// so we'll just overwrite the method with one that throws a
// BadMethodCallException
foreach($this->scopes as $name => $scope) {
$builder->macro($name, function() use($name) {
$className = get_class($this);
throw new \BadMethodCallException("Call to undefined method {$className}::{$name}()");
});
}
}
public function addScope($name, \Closure $scope) {
$this->scopes[$name] = $scope;
}
}
The ServiceProvider and Composer File
app/lib/PhpMyCoder/Repository/RepositoryServiceProvider.php:
<?php namespace PhpMyCoder\Repository;
use Illuminate\Support\ServiceProvider;
use PhpMyCoder\Repository\Order\EloquentOrderRepository;
class RepositoryServiceProvider extends ServiceProvider {
public function register() {
// Bind the repository interface to the eloquent repository class
$this->app->bind('PhpMyCoder\Repository\Order\OrderRepository', function() {
return new EloquentOrderRepository(new \Order);
});
}
}
Be sure to add this service provider to the providers array in the app.php config:
'PhpMyCoder\Repository\RepositoryServiceProvider',
And then add the app/lib to composer's autoload
"autoload": {
"psr-0": {
"PhpMyCoder\\": "app/lib"
},
/* etc... */
},
This will require a composer.phar dump-autoload.
The Models
app/models/Customer.php:
<?php
class Customer extends Eloquent {
public function orders() {
return $this->hasMany('Order');
}
}
Notice that for brevity, I've excluded writing a repository for Customer, but in a real application you should.
app/model/Order.php:
<?php
class Order extends Eloquent {
public function customer() {
return $this->belongsTo('Customer');
}
}
Notice how the scope is not longer stored in the Order model. This makes more structural sense, because the collection level (repository) should be responsible for scopes applying to all orders while Order should only be concerned with details specific to one order. For this demo to work, order must have an integer foreign key customer_id to customers.id and a boolean flag finished.
Usage in the Controller
app/controllers/OrderController.php:
<?php
// IoC will handle passing our controller the proper instance
use PhpMyCoder\Repository\Order\OrderRepository;
class OrderController extends BaseController {
protected $orderRepository;
public function __construct(OrderRepository $orderRepository) {
$this->orderRepository = $orderRepository;
}
public function test() {
$allOrders = $this->orderRepository->all();
// Our repository can handle scope calls similarly to how
// Eloquent models handle them
$finishedOrders = $this->orderRepository->finished();
// If we had made one, we would instead use a customer repository
// Notice though how the relation query also has order scopes
$finishedOrdersForCustomer = Customer::find(1)->orders()->finished();
}
}
Our repository not only contains the scopes for the child model, which is more SOLID. They also come with the ability to handle calls to the scope like a real Eloquent model would. And they add all scopes to each query created by the model so that you have access to them when retrieving related models.
Problems with this Approach
A lot of code for little functionality: arguably too much to accomplish the desired result
It's hacky: macros on Illuminate\Database\Eloquent\Builder and Illuminate\Database\Eloquent\ScopeInterface (in conjunction with Illuminate\Database\Eloquent\Model::addGlobalScope) are likely used in ways they weren't intended to be
It requires instantiation of the repository (MAJOR ISSUE): if you're within the CustomerController and you only have instantiated CustomerRepository, $this->customerRepository->find(1)->orders()->finished()->get() won't work as expected (the finished() macro/scope won't be added to each Order query unless you instantiate OrderRepository).
I'll investigate if there is a more elegant solution (which remedies the issues listed above), but this is the best solution I can find thus far.
Related Resources on the Repository Pattern
Creating flexible Controllers in Laravel 4 using Repositories
Eloquent tricks for better Repositories
Is there a clean way to enable certain models to be ordered by a property by default?
It could work by extending the laravel's QueryBuilder, but to do so, you'll have to rewire some of it's core features - bad practice.
reason
The main point of doing this is - one of my models get's heavily reused by many others and right now you have to resort the order over and over again. Even when using a closure for this - you still have to call it. It would be much better to be able to apply a default sorting, so everyone who uses this model, and does not provide custom sorting options, will receive records sorted by the default option. Using a repository is not an option here, because it get's eager loaded.
SOLUTION
Extending the base model:
protected $orderBy;
protected $orderDirection = 'ASC';
public function scopeOrdered($query)
{
if ($this->orderBy)
{
return $query->orderBy($this->orderBy, $this->orderDirection);
}
return $query;
}
public function scopeGetOrdered($query)
{
return $this->scopeOrdered($query)->get();
}
In your model:
protected $orderBy = 'property';
protected $orderDirection = 'DESC';
// ordering eager loaded relation
public function anotherModel()
{
return $this->belongsToMany('SomeModel', 'some_table')->ordered();
}
In your controller:
MyModel::with('anotherModel')->getOrdered();
// or
MyModel::with('anotherModel')->ordered()->first();
Before Laravel 5.2
Nowadays we can solve this problem also with global scopes, introduced in Laravel 4.2 (correct me if I'm wrong). We can define a scope class like this:
<?php namespace App;
use Illuminate\Database\Eloquent\Builder;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\ScopeInterface;
class OrderScope implements ScopeInterface {
private $column;
private $direction;
public function __construct($column, $direction = 'asc')
{
$this->column = $column;
$this->direction = $direction;
}
public function apply(Builder $builder, Model $model)
{
$builder->orderBy($this->column, $this->direction);
// optional macro to undo the global scope
$builder->macro('unordered', function (Builder $builder) {
$this->remove($builder, $builder->getModel());
return $builder;
});
}
public function remove(Builder $builder, Model $model)
{
$query = $builder->getQuery();
$query->orders = collect($query->orders)->reject(function ($order) {
return $order['column'] == $this->column && $order['direction'] == $this->direction;
})->values()->all();
if (count($query->orders) == 0) {
$query->orders = null;
}
}
}
Then, in your model, you can add the scope in the boot() method:
protected static function boot() {
parent::boot();
static::addGlobalScope(new OrderScope('date', 'desc'));
}
Now the model is ordered by default. Note that if you define the order also manually in the query: MyModel::orderBy('some_column'), then it will only add it as a secondary ordering (used when values of the first ordering are the same), and it will not override. To make it possible to use another ordering manually, I added an (optional) macro (see above), and then you can do: MyModel::unordered()->orderBy('some_column')->get().
Laravel 5.2 and up
Laravel 5.2 introduced a much cleaner way to work with global scopes. Now, the only thing we have to write is the following:
<?php namespace App;
use Illuminate\Database\Eloquent\Builder;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Scope;
class OrderScope implements Scope
{
private $column;
private $direction;
public function __construct($column, $direction = 'asc')
{
$this->column = $column;
$this->direction = $direction;
}
public function apply(Builder $builder, Model $model)
{
$builder->orderBy($this->column, $this->direction);
}
}
Then, in your model, you can add the scope in the boot() method:
protected static function boot() {
parent::boot();
static::addGlobalScope(new OrderScope('date', 'desc'));
}
To remove the global scope, simply use:
MyModel::withoutGlobalScope(OrderScope::class)->get();
Solution without extra scope class
If you don't like to have a whole class for the scope, you can (since Laravel 5.2) also define the global scope inline, in your model's boot() method:
protected static function boot() {
parent::boot();
static::addGlobalScope('order', function (Builder $builder) {
$builder->orderBy('date', 'desc');
});
}
You can remove this global scope using this:
MyModel::withoutGlobalScope('order')->get();
In Laravel 5.7, you can now simply use addGlobalScope inside the model's boot function:
use Illuminate\Database\Eloquent\Builder;
protected static function boot()
{
parent::boot();
static::addGlobalScope('order', function (Builder $builder) {
$builder->orderBy('created_at', 'desc');
});
}
In the above example, I order the model by created_at desc to get the most recent records first. You can change that to fit your needs.
Another way of doing this could be by overriding the newQuery method in your model class. This only works if you never, ever want results to be ordered by another field (since adding another ->orderBy() later won't remove this default one). So this is probably not what you'd normally want to do, but if you have a requirement to always sort a certain way, then this will work:
protected $orderBy;
protected $orderDirection = 'asc';
/**
* Get a new query builder for the model's table.
*
* #param bool $ordered
* #return \Illuminate\Database\Eloquent\Builder
*/
public function newQuery($ordered = true)
{
$query = parent::newQuery();
if (empty($ordered)) {
return $query;
}
return $query->orderBy($this->orderBy, $this->orderDirection);
}
Yes you would need to extend Eloquent to always do this as standard for any query. What's wrong with adding an order by statement to the query when you need it ordered? That is the cleanest way, ie, you dont need to 'unhack' Eloquent to get results by natural order.
MyModel::orderBy('created_at', 'asc')->get();
Other than that the closest thing to what you want would be to create query scopes in your models.
public function scopeOrdered($query)
{
return $query->orderBy('created_at', 'asc')->get();
}
You can then call ordered as a method instead of get to retrieve your ordered results.
$data = MyModel::where('foo', '=', 'bar')->ordered();
If you wanted this across different models you could create a base class and just extend it to the models you want to have access to this scoped method.
you should use eloquent global scope that can apply to all queries(also you can set parameter for it).
And for relations you can use this useful trick:
class Category extends Model {
public function posts(){
return $this->hasMany('App\Models\Post')->orderBy('title');
}
}
this will add order by to all posts when we get them from a category.
If you add an order by to your query, this default order by will cancel!
An slightly improved answer given by Joshua Jabbour
you can use the code he offered in a Trait, and then add that trait to the models where you want them to be ordered.
<?php
namespace App\Traits;
trait AppOrdered {
protected $orderBy = 'created_at';
protected $orderDirection = 'desc';
public function newQuery($ordered = true)
{
$query = parent::newQuery();
if (empty($ordered)) {
return $query;
}
return $query->orderBy($this->orderBy, $this->orderDirection);
}
}
then in whichever model you want the data to be ordered you can use use :
class PostsModel extends Model {
use AppOrdered;
....
now everytime you request that model, data will be ordered, that's somehow more organized, but my answers is Jabbour's answer.
I built a mini Laravel package that can add default orderBy in your Eloquent model.
Using the DefaultOrderBy trait of this package, you can set the default column you want to orderBy.
use Stephenjude/DefaultModelSorting/Traits/DefaultOrderBy;
class Article extends Model
{
use DefaultOrderBy;
protected static $orderByColumn = 'title';
}
You can also set the default orderBy direction by setting the $orderByColumnDirection property.
protected static $orderByColumnDirection = 'desc';
A note from my experience, never to use orderBy and GroupBy such term on global scope. Otherwise you will easily face database errors while fetching related models in other places.
Error may be something like:
"ORDER BY "created_at" is ambiguous"
In such case the solution can be giving table name before column names in your query scope.
"ORDER BY posts.created_at"
Thanks.