Delete Cache on save/update

Published 2 years ago by lorvent


I have around 20 models and since i need to get data from many models for each request, i am saving them into cache.

Now, if a user creates/updates any record into those cached models, i want to flush cache.

is there any proper way to do it? like using events, model listeners etc?





Sorry, that doesn't answer my question.

i know Cache::flush(); but i want a way to delete cache only when a new row is inserted or existing row updated for certain tables/models.


I'd do this by keying cached data for each entity uniquely. Then on save/delete clear just that key.

I'd probably use a trait for that, tack on to the model methods with a cache layer. So everything uses normal model calls, but your trait pulls from cache if the cache exists for the query or if not creates the cache. Then on save/delete clears the cache for that entity automatically.

It'd probably be a bit of work to make the trait initially, but it'd be reusable everywhere. And frankly, I bet there's a package for it out there already.

Alternatively just leverage cache in your DB Engine.


Currently i am deleting cache in store and update methods but i guess there must be an elegant way using model listeners, events etc.


Personally, I don't use events like that. I think of events as things triggered by and affecting users. For example, user registers on the site, an email is sent to them. You wouldn't event User signs up, we create their entry in the DB. Query cache is a machine thing, so in my mind, not something I'd handle in events.

Personally I think the trait approach would be one of the most elegant. It's reusable, maintains normal functionality while adding functionality to a model by simply implementing an extra trait, and is really straight forward to understand a year or two from now, or by someone else. It makes it easy to see that a model is using cache for queries since that model implements a trait. This approach keeps the new functionality encapsulated into one Trait.

With events, that's not really attached to a model anymore and now when debugging a query issue, you have to figure out that events are triggering cache resets. And then for using the query cache on select, that doesn't really fit into events at all, does it? You can't really listen for a select event then intercept the query and feed it from cache. So that part will always be somewhere else. It's just a less encapsulated approach, making it less portable, and tougher to debug.


Excellent explanation @nickwest thanks for taking your time to explain it so nice

@rsdev000 thanks for the links, actually i mean those event fires only....since they are fired automatically, i can clear cache.

ofcourse i already have a cache clear route, which i hit whenever i feel something wrong going on.

Please sign in or create an account to participate in this conversation.