HI @jm-sky thank you for submitting the PR.

Can you explain how cache-time is different than cooldown, which already exists?

I understand that Cache Cool-down delays invalidation of models cache.

My Caching time option adds automatic invalidation after n-seconds.

Basic flow:

• first CountryModel::all() - query database, set cache for n-seconds
• next CountryModel::all() - loads result from cache
• after n-seconds CountryModel::all() - query database, set cache for n-seconds

is this PR a good missing feature?

I didn't know until now that, this package cache everything forever(until something change, or we purge it ourselves).
why don't we have a duration config for caching?

is this PR a good missing feature?

I didn't know until now that, this package cache everything forever(until something change, or we purge it ourselves). why don't we have a duration config for caching?

Yea, I'm not sure this is consistent with the goals of this package. I don't see why you would want to force expiring of cache when it invalidates itself. If there are problems with cached items not getting invalidated, that should be addressed.

Thanks anyway. It's useful package.

I've just extended Your classes in my project.

I do so in case of raw inserts into database, that could occur in case of data integration at database level.

@jm-sky if you do have raw inserts in an automated process, the solution would be to invalidate the cache for the affected models after the script has completed. As a matter of process, if you are scripting the inserts within Laravel (in a console command, or wherever), the model should always be used to perform the insert.

Is this merged?

Is this merged?

Hi @danpalmieri, this was not merged, as it goes against the core intent of the package.