Is this Package Abandomed?

[dutsik]

While it might offer efficiency, there are concerns about its long-term viability.

[mikebronner]

@dutsik your concerns are warranted. Since initially developing the package, I have changed my stance on database caching and actually no longer recommend it. Many things have changed in the Laravel landscape, and with the introduction of Livewire, the entire page does not need to be front-loaded. Using a mix of database query optimization, Livewire, and intentional occasional caching mechanisms has proven to me to be far more useful than blanket-caching everything.

Because of that, the fact that I no longer use this package myself, and my lack of availability, I have been pondering how I move forward with this package. I fully intend to get it updated to Laravel 12. However, I have to see if I open it up to a maintainer, or mark the package as deprecated, with Laravel 12 possibly being the last update.

I would love to hear people's feedback on this. If you are still using the package, what is your use-case? Why is it important?

Thanks!

[Okipa]

Hi there, we have installed your package on a SAAS for performance improvements on specific and highly requested high-level models.

It seems to work pretty well for the moment, allowing us to reduce the number of database requests that were repeated before.

It is a quite simple use case, only for a few models, but I think that your package is quite valuable for this kind of case (in case of multi-tenancy navigation for example). However, we are also concerned about maintenance issues if this package wouldn't be maintained anymore. We would in this case abandon its usage, in order to setup our own model caching solution.

[mikebronner]

@Okipa thank you for your feedback. Your use-case makes a lot of sense. Laravel 12 compatibility has just been added.

My current plan is to keep the package functional, relying on community contributions for any big functional changes, and trying to keep it up-to-date with any Eloquent changes.

[Okipa]

Thanks for your answer!
Everything seems to work on our end, your package is currently on our staging instance but I plan to push it in production shortly.

[mikebronner]

Keeping this open for any feedback on use-cases others have as well.

[daika7ana]

I am using this package in production for 3.5 years in a SaaS.
This is used on models where there's a lot of reads.
Some examples of this being:

• UserAddresses
• FixedDropoffLocations
• ApplicationSettings
• WebhookCallbackLogs - this being used as an insert-only type of table where we do lookups.
• Notes - polymorphic insert-only type of table.

I can wholeheartedly say that this packages has been a reliable timesaver.
The only gotcha moment, that I've had so far, was doing mass-updates with Model::query()->upsert([...]) and forgetting to purge the model-cache afterwards.

[Okipa]

Interesting, my biggest concern about this package is the way the cache auto-invalidâtes itself when a model is updated.

I understand that you only use model caching on non-updatable models, which resolves this case.

On our end, we are using it on models that can be updated at low frequency, but cache invalidating must be reliable when an update is triggered.

I was wondering if you could give us the main principles of cache auto-invalidating of your package @mikebronner. How is this working and what caveats may we encounter ?

I quickly started digging but it seems to rely on events, which is not so easy to track.

[daika7ana]

As long as you're using Eloquent so that you're triggering Model events, everything is handled here (except for the restore event when restoring models that were soft-deleted).

Hence why I've mentioned the caveat above.
The package relies on Model Events to be triggered to handle cache-invalidation, and if you're using mass assigment/update these events are not triggered (as mentioned here)

One aspect that can be improved in this package would be a way of invalidating the cache directly from the code using a Facade after a mass assignment/update instead of having to rely on an Artisan call like:

Artisan::call('modelCache:clear', ['--model' => 'App\Model']);

[Okipa]

Thanks @daika7ana 🙏

@mikebronner I just seen a potential issue when using pivot models (https://laravel.com/docs/12.x/eloquent-relationships#defining-custom-intermediate-table-models).
Cache is not invalidated once an attachement or detachment is processed trough such a pivot model, in fact, the action is not detected at all in pivotSynced, pivotAttached, ... events.
Is this something that is not yet covered by the package ?