Caching eloquent models since laravel 5

caching models is not different than caching anything else :) same syntax in the docs

True, but in that case, you'll have to add the cache function somewhere, and cache it yourself with cache tags. Is there an overall way to set it for the model, and make it a smart caching like the old remember function? Or do you really have to cache it manually somewhere in the models yourself? Bart

Bump

anyone?

Hey @BartHuis !

Maybe you should give a try to the package made by @Omranic : The art of using Repositories in Laravel 5.3

thanks @RomainLanz , looks nice, but it seems a bit strange to use an external package for a basic thing as caching. is there really no buildin way anymore to cache without making own cache tags?

@BartHuis I never used it, because I never actually needed it, website was spinning without issue, but I did make note on that feature when the website got bigger. It suprised me to hear that it got removed, it's handy, easy to use and can give website a big boost, shame on you Laravel!

I did read that there was a package that allows you to have that function back again: https://github.com/dwightwatson/rememberable Disclaimer: Did not test, nor do I know the author.

Got no idea why they would delete a function like that ;(

We're also thinking about building it without cache in first place, and do some performance testing on the new server with ddos like request and check how the performance is, and then when needed building in cache later.

But we still like to know the idea behind this, so we know laravel better...

Well, if I have to guess, it's less open and you are forced to use a set structure, or something like that I think. Maybe :P?

$value = Cache::remember('users', $minutes, function() {
    return DB::table('users')->get();
});

I think that something like this will be the alternative, for that remember function (or replacement), seems easy enough. It even faster because it just caches the content (so subquery's don't need to be cached manually), though I can imagine people might have trouble with the naming, haha.

'En goedemorgen, btw.'

is that also working with models instead of DB:: ? because that's something you won't use as long as it's possible to use model instead of DB

goedemiddag bijna, dacht het al aan je naam te zien, maar ik mistte je vlaggetje ;) mijn engels is niet altijd even goed, dus als ik iets niet goed heb begrepen, let me know....

Of course, it could work without any issue. When you call "->get()" You will receive the results, this will be cached by "Cache::remember", so it's pretty much just getting (when it already exist) and putting data (when there is no data and/or cache timer is expired) in cache.

but wasn't the remember function removed from 5 and up?

No.

Look at the Cache Documentation chapter Retrieve & Store.

Yes, but that is the eloquent function that caches the query. The Cache still has the remember function.

ah, just looked at that function, but there you still have to give your own cache tags. that's just the thing we dont want.

• i have a table products with 20 products.
• a user performs a search and 15 products will be shown.
• a second user performs the same search, we want it to be cached, so no new database query
• we update one product
• the cache where that products are in, have to be deleted
• a third user performs the same search as the first 2 persons, then it will build the new cache

the @Omranic way would cache it including the options given (where, offset, limit etc).

The only thing what I think of now, is that I think that the package of @Omranic doesn't handle deletion of cache when updating, bezause you give a time limit.... you'll need something like the russion doll caching from the video here at laracast, but there's no update on that one for models, it only worked with views...

@BartHuis It's my pleasure you found our package useful.

If I understand your last concern well, then let me say that the package actually flush invalid cache on every entity update: https://github.com/rinvex/repository/blob/4de4c2fed88751ed3b35eb774fd4f3e82717b245/src/Listeners/RepositoryEventListener.php#L65

On on every user update, users cache will be flushed. And similarly with other entities. Is that's your concern, or maybe something else?

@Omranic that sounds good.

i have two other concerns here:

• Why isn't this possible out of the box with laravel. I should think automatisch cache without defining your keys should be one of the core functions of a cache system?
• When you build an larger application, you would like to cache nested items. For example: I have categories with products. I have a request for a specific selection of catagories with products. The products must be cached, the categories with the products are cached, and the selection is cached. When you update one product, that cache has to be removed, the parent categorie cache had to be removed, and the selection cache has to be removed, but when requesting the selection again, alle categories without changed products can be get from the cache and all products that are not changed in the changed category, can be got from the cache. only the changed product can be taken from the db again, put into cache, and the category can be cached again with all the other allready cached products, and the selection can be cached again with all the other allready cached categories. The so called "russian doll caching", cache nested items. @JeffreyWay allready made video series on that: https://laracasts.com/series/russian-doll-caching-in-laravel only that's based on views, he was planning to make an extra video on applying the idea on models, reminded him today on twitter if he would look at that. Maybe there are better way's to do it since the last video's on that topic...

I totally agree, but currently I don't see anyway that Laravel can do so out of the box. I hope that would be a core feature one day, and we're at the point there's no need to develop external packages for that.

Even our package rinvex/repository solves some of the challenges mentioned before, it's still flush the whole tagged cache, which may not be the optimum solution. Russian doll caching is a great methodology, but still I can't figure a way to implement it on that scale or get benefit of it in our package.

There's still a room for more enhancements on the caching layer at Laravel's core, and until then I think such discussions are very helpful evolving a good alternatives :) Don't you agree?

True :)

We'll look at our core project first, and how its performing without cache. when we do need cache, i think we'll dive deeper into the possibilities, and maybe we can make a combination on russian doll and yours.

Any updates on this? I too fail to understand why this was removed. Can we ask any actual Laravel developers about that?