Download the PHP package knovator/laravel-model-caching without Composer

Model Caching for Laravel

Supporting This Package

This is an MIT-licensed open source project with its ongoing development made possible by the support of the community. If you'd like to support this, and our other packages, please consider becoming a sponsor.

Impetus

I created this package in response to a client project that had complex, nested forms with many <select>'s that resulted in over 700 database queries on one page. I needed a package that abstracted the caching process out of the model for me, and one that would let me cache custom queries, as well as cache model relationships. This package is an attempt to address those requirements.

Features

• automatic, self-invalidating relationship (only eager-loading) caching.
• automatic, self-invalidating model query caching.
• automatic use of cache tags for cache providers that support them (will flush entire cache for providers that don't).

Cache Drivers

This package is best suited for taggable cache drivers:

It will not work with non-taggable drivers:

Requirements

• Laravel 6.0+

Possible Conflicting Packages

Any packages that override newEloquentModel() from the Model class will likely conflict with this package. Of course, any packages that implement their own Querybuilder class effectively circumvent this package, rendering them incompatible.

The following are packages we have identified as incompatible:

• grimzy/laravel-mysql-spatial
• fico7489/laravel-pivot
• chelout/laravel-relationship-events
• spatie/laravel-query-builder
• dwightwatson/rememberable

Things That Don't Work Currently

The following items currently do no work with this package:

Installation

Be sure to not require a specific version of this package when requiring it:

Upgrade Notes

0.6.0

The environment and config variables for disabling this package have changed.

• If you have previously published the config file, publish it again, and adjust as necessary:

• If you have disabled the package in your .env file, change the entry from MODEL_CACHE_DISABLED=true to MODEL_CACHE_ENABLED=false.

0.5.0

The following implementations have changed (see the respective sections below):

• model-specific cache prefix

Configuration

Recommended (Optional) Custom Cache Store

If you would like to use a different cache store than the default one used by your Laravel application, you may do so by setting the MODEL_CACHE_STORE environment variable in your .env file to the name of a cache store configured in config/cache.php (you can define any custom cache store based on your specific needs there). For example:

Usage

For best performance a taggable cache provider is recommended (redis, memcached). While this is optional, using a non-taggable cache provider will mean that the entire cache is cleared each time a model is created, saved, updated, or deleted.

For ease of maintenance, I would recommend adding a BaseModel model that uses Cachable, from which all your other models are extended. If you don't want to do that, simply extend your models directly from CachedModel.

Here's an example BaseModel class:

Multiple Database Connections

Thanks to @dtvmedia for suggestion this feature. This is actually a more robust solution than cache-prefixes.

Keeping keys separate for multiple database connections is automatically handled. This is especially important for multi-tenant applications, and of course any application using multiple database connections.

Optional Cache Key Prefix

Thanks to @lucian-dragomir for suggesting this feature! You can use cache key prefixing to keep cache entries separate for multi-tenant applications. For this it is recommended to add the Cachable trait to a base model, then set the cache key prefix config value there.

Here's is an example:

The cache prefix can also be set in the configuration to prefix all cached models across the board:

Exception: User Model

I would not recommend caching the user model, as it is a special case, since it extends Illuminate\Foundation\Auth\User. Overriding that would break functionality. Not only that, but it probably isn't a good idea to cache the user model anyway, since you always want to pull the most up-to-date info on it.

Experimental: Cache Cool-down In Specific Models

In some instances, you may want to add a cache invalidation cool-down period. For example you might have a busy site where comments are submitted at a high rate, and you don't want every comment submission to invalidate the cache. While I don't necessarily recommend this, you might experiment it's effectiveness.

To use it, it must be enabled in the model (or base model if you want to use it on multiple or all models):

After that it can be implemented in queries:

or:

Disabling Caching of Queries

There are two methods by which model-caching can be disabled:

1. Use ->disableCache() in a query-by-query instance.
2. Set MODEL_CACHE_ENABLED=false in your .env file.
3. If you only need to disable the cache for a block of code, or for non- eloquent queries, this is probably the better option:

Recommendation: use option #1 in all your seeder queries to avoid pulling in cached information when reseeding multiple times. You can disable a given query by using disableCache() anywhere in the query chain. For example:

Manual Flushing of Specific Model

You can flush the cache of a specific model using the following artisan command:

This comes in handy when manually making updates to the database. You could also trigger this after making updates to the database from sources outside your Laravel app.

Summary

That's all you need to do. All model queries and relationships are now cached!

In testing this has optimized performance on some pages up to 900%! Most often you should see somewhere around 100% performance increase.

Commitment to Quality

During package development I try as best as possible to embrace good design and development practices, to help ensure that this package is as good as it can be. My checklist for package development includes:

• ✅ Achieve as close to 100% code coverage as possible using unit tests.
• ✅ Eliminate any issues identified by SensioLabs Insight and Scrutinizer.
• ✅ Be fully PSR1, PSR2, and PSR4 compliant.
• ✅ Include comprehensive documentation in README.md.
• ✅ Provide an up-to-date CHANGELOG.md which adheres to the format outlined at https://keepachangelog.com.
• ✅ Have no PHPMD or PHPCS warnings throughout all code.

#