The cache system in getSettings() cached values "forever." That's bad.

[uberbrady]

The Cache::rememberForever() invocation we were doing was way, way too aggressive - literally caching forever. Newly-updated Settings would end up not reflecting changes in the settings table until you could run php artisan cache:clear.

This changes that caching system to use a simple static property as an in-memory cache so that multiple invocations of Setting::getSettings() would only hit the disk once - per request. On the next request, it will hit the disk again - but, again, only once.

I tested this in Tinker multiple times by changing the database directly and repeatedly re-invoking getSettings() - which seemed to work as expected.

[what-the-diff]

• The cache property was added to the Setting model
• Cache::forget(Setting::APP_SETTINGS_KEY) is removed from saved() method in SettingObserver class

[snipe]

Wouldn't this forget the previous cache, therefore NOT remembering it forever?

[snipe]

Newly-updated Settings would end up not reflecting changes in the settings table until you could run php artisan cache:clear.

That's not exactly true - anything made outside of a normal ->save() need to be cleared, since it would skip the SettingsObseverver's saved() method - which would only happen in a migration where we're adding a new column with a default value, no?

I'm not 100% convinced that this is the correct solution, but I'm willing to be convinced :)

[uberbrady]

Well, I don't need to convince you anymore since you already merged it :P

[snipe]

Not a hill I was willing to die on :P