You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+74Lines changed: 74 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -135,6 +135,80 @@ class Kid extends Model
135
135
Kid::flushQueryCache();
136
136
```
137
137
138
+
## Full Automatic Invalidation
139
+
140
+
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.
141
+
142
+
```php
143
+
class Page extends Model
144
+
{
145
+
use QueryCacheable;
146
+
147
+
/**
148
+
* Invalidate the cache automatically
149
+
* upon update in the database.
150
+
*/
151
+
protected static $flushCacheOnUpdate = true;
152
+
}
153
+
```
154
+
155
+
When you set up the `$flushCacheOnUpdate` variable, the package attaches an observer to your model, and any `created`, `updated`, `deleted`, `forceDeleted` or `restored` event will trigger the cache invalidation.
156
+
157
+
> In order for auto-flush to 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.
158
+
159
+
## Partial Automatic Invalidation
160
+
161
+
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 one of them.
162
+
163
+
To do this, overwrite your `getCacheTagsToInvalidateOnUpdate()` method in your model:
164
+
165
+
```php
166
+
class Page extends Model
167
+
{
168
+
use QueryCacheable;
169
+
170
+
/**
171
+
* Invalidate the cache automatically
172
+
* upon update in the database.
173
+
*/
174
+
protected static $flushCacheOnUpdate = true;
175
+
176
+
/**
177
+
* When invalidating automatically on update, you can specify
178
+
* which tags to invalidate.
179
+
*
180
+
* @return array
181
+
*/
182
+
public function getCacheTagsToInvalidateOnUpdate(): array
183
+
{
184
+
return [
185
+
'query1',
186
+
];
187
+
}
188
+
}
189
+
190
+
$query1 = Page::cacheFor(60)
191
+
->cacheTags(['query1'])
192
+
->get();
193
+
194
+
$query2 = Page::cacheFor(60)
195
+
->cacheTags(['query2'])
196
+
->get();
197
+
198
+
// The $query1 gets invalidated
199
+
// but $query2 will still hit from cache if re-called.
200
+
201
+
$page = Page::first();
202
+
203
+
$page->update([
204
+
'name' => 'Reddit',
205
+
]);
206
+
```
207
+
208
+
**Please keep in mind: Setting `$flushCacheOnUpdate` to `true` and not specifying individual tags to invalidate will lead to [Full Automatic Invalidation](#full-automatic-invalidation) since the default tags to invalidate are the base tags and you need at least one tag to invalidate.**
209
+
210
+
**Not specifying a tag to invalidate fallbacks to the set of base tags, thus leading to Full Automatic Invalidation.**
211
+
138
212
## Relationship Caching
139
213
140
214
Relationships are just another queries. They can be intercepted and modified before the database is hit with the query. The following example needs the `Order` model (or the model associated with the `orders` relationship) to include the `QueryCacheable` trait.
0 commit comments