I am intending to build a caching layer for an app that I am working on. The current Laravel 5.2 caching library is very helpful when it comes to remembering queries and shoving them in memcached for an X amount of time.
Let's say I shove a note/1 into the cache. Now a user updates the cache. I see no mechanism of invalidation here. Do I have to build this on my own or is there some hidden Laravel magic ?
Basically, a user creates a note. It goes into cache and gets remembered forever. Then, he accesses it again. It's a cache HIT. Now, he changes a word in it. I want a mechanism of invalidating, re-caching and returning the item.
Using $cache->remember(key, time_in_minutes, func) allows you to automatically invalidate after X minutes.
You can of course manually invalidate using $cache->forget(key), which will triggerfuncto be executed becausekey` will no longer be found.
@someguy123 Hey man, thanks for your reply. That seems reasonable. Can you have a glance at this and see if Laravel does something like this internally, or we should craft stuff like this on our own. https://signalvnoise.com/posts/3113-how-key-based-cache-expiration-works
Anyway, how do you suggest I build a invalidation detection mechanism around what we have with Laravel right now. A digest of the cached copy and comparing it with the updated copy? Would that work? I have a couple of ideas. I am just looking to see what others say.
The way I invalidate/validate caching is via model events. So when these events fire, you can act appropriately for your caching strategy.
https://laravel.com/docs/5.1/eloquent#events
I am sure some people may disagree with this strategy but I found this to be easiest way for me to deal with this problem.
@crazytoon Makes sense. I shall try that. On another note, if I am eager loading and I cache a related model separately, would the eager loading call respect the cached item or hit the database directly. How should I approach this. maybe @someguy123 can chip in too.
@aligajani interested too in how to cache with eager loading.
@cristian9509 Yes, that too! @TaylorOtwell can chip in here too. I am interested in the internals of how eager loading and caching would work in Laravel 5.2! Say I have a board.
This board has 4 item types, W,X,Y,Z. Now, if the item Y is updated, should we invalidate the entire eager loading query for board, of just the specific Y. How to deal with cache at such a fine grained level?
@aligajani I have a project where I do a bunch of complex queries (for some user ADS) that use eager loading but which I can cache and reuse since they are fixed to the user location. If I could understand how eager loading works with cache I can really get a good picture on how to use it.
This board has 4 item types, W,X,Y,Z. Now, if the item Y is updated, should we invalidate the entire eager loading query for board, of just the specific Y. How to deal with cache at such a fine grained level?
See the recent Laracasts course on Russian doll caching.
Anyone found a good Solution on this?
@MikeHopley - Russian Doll Caching is great but it is specifically on the view side of things, not for db calls in the backend (though there can be an overlap if view partials are cascading)
Please or to participate in this conversation.