🍸Automatic Invalidation
To speed up the scaffolding of invalidation within your app, you can specify the model to auto-flush the cache upon any time records gets created, updated, or deleted.
When you set up the $flushCacheOnUpdate
property, the package attaches an observer to your model and any created
, updated
, deleted
, forceDeleted
or restored
event will trigger the cache invalidation.
In order to make auto-flush work, you will need at least one base tag. Out-of-the-box, the model has a base tag set. In some cases, if you have overwritten the `getCacheBaseTags()` with an empty array, it might not work.
Selective cache invalidation
In some cases, you might not want to invalidate the whole cache of a specific model. Perhaps you got two queries that run individually and want to invalidate the cache only for them and not for all the models.
To do this, overwrite your getCacheTagsToInvalidateOnUpdate()
method in your model:
The idea behind this configuration is that we can bind page:[some_id]
tag (where some_id
is a given ID from the input) to the queries where we try to get the page by ID and attach thepages
tag to the queries where we get all the pages.
When the page model gets changed, it will invalidate the query in which we retrieve the page and the one that lists the page, thus invalidating exactly the two queries.
Please keep in mind: Setting $flushCacheOnUpdate
to true
and not specifying individual tags to invalidate will lead to a global flush for that model since the default tags to invalidate are the base tags and you need at least one tag to invalidate.
Not specifying a tag to invalidate fallbacks to the set of base tags, thus leading to Full Automatic Invalidation.
Last updated