Cache backend consistency runtime check and graceful downgrade mecanism

This makes the system more robust at the cost of less than (number of bins) * function calls. I needed it while I was iterating on development phases on some custom projects, and this code has proven to me to be working quite well. Well, on the D6 cache backport module it did, but this patch is basically almost the same code, with better Drupal code convention support and better documentation. I tested some use cases on a D7 instance even run some UNIT tests (well, not every of them because my box is dawn slow).

@#2
Sounds right for the method naming. Doesn't really care about the name as soon as it express the purpose.
Didn't see the DrupalFakeCache, probably should it live in the cache.inc, I mean, is the cache-install.inc loaded on normal runtime?

@#3
I'll provide a clearer patch.

Since a misconfigured settings.php file can lead to WSOD with the actual cache.inc, I'm switching this down to bugfix, not feature request anymore.

DrupalFakeCache embeds specific code for install time (messes up with Database) what a real Dummy/Stumb/Null/Neutral object should not, maybe should it be renamed to DrupalInstallCache instead, and DrupalFakeCache should be my own implementation? Plus, a real Null Object implementation shouldn't rely on a base class that's a totally messed-up and broken design.

Yes, I'm rewriting the patch.

Ok, here is a more complicated patch, implementing Damien suggestions:

• Renamed legacy DrupalFakeCache as DrupalInstallCache, which should probably be better for code comprehension.
• Patched install related files in order for them to use the DrupalInstallCache.
• DrupalFakeCache is now defined in the cache.inc which makes more sense since it can be used voluntarely by site admins or developers to do testing. It is now a real Null Object implementation that does not extends the DrupalDatabaseCache anymore.
• Rewrote _cache_get_object() with more checks. Default backend class is statically cached, if it fails once, the system downgrades to the null implementation instead. This means that misconfigured sites will suffer from performance problems, but won't WSOD anymore.
• Renamed the checkEnv() method as isHealthy() as Damien suggested (it makes sense to me).

There are a few things to consider here, but I think this patch can work as-is without going further, nevertheless:

• DrupalInstallCache is an insane and unnecessary code indirection, and should be definitely removed as the install-cache.inc file. It should use the real null implementation aKa DrupalFakeCache instead.

EDIT: Fixed some typo errors.

Switching to needs review.

We related all of that, and my implementation actually keeps the installation backend, but renaming it, while it created a real fake implementation into a simpler version which is actually a real null object pattern implementation (that get the name of the older one, therefore keeping backward compatibility).

The try/catch implementation is not likely to be useful here because we cannot catch while instanciating based on the get() errors.

My whole patch is about not ending up with a WSOD (which with the actual code can happen) and keeping full API compatibility. It adds some new stuff but there are basically dormant if you don't use it and doesn't modify the actual API.

Hello, waking up this issue since I'm actually developing cache backend, it's the right time for me to have a final answer about this issue.

@Damien Tournoud you made pertinent comments, now that I fulfilled every one of them, should be the right time for a go or a no go.

@catch I think this issue is not incompatible with the others being opened, and the isHealthy() method could be the right one were to implement the lazy table creation (or anything else depending on the backend).

Ok, I don't see any problems with that suggestion, let me redo the patch and we could then discuss it further.

EDIT: But I really don't see why loosing the generic aspect, when we look at this issue: #402896: Introduce DrupalCacheArray and use it for drupal_get_schema() the proposition is meant to give a generic solution (and a good candidate for backport) for potential modules or other core usage.

Maybe the terminology indeed can be changed, the plugin word can be confusing; But the generic aspect, even if not being used right now, is still a potential future benefit.

New patch attached, did on latest 7.x, should pass on 8.x as well.

Changes:

• As required, removed all plugin word occurences, changed the interface name to DrupalCriticalCacheInterface.
• Changed a bit documentation to fit this change.
• Removed useless default sample implementation on DrupalDatabaseCache
• Removed useless cache-install.inc file and make the install using the DrupalFakeCache backend instead.

Forgot the patch..

Wrong tab, forget it.

Attached patch following latest commit from catch API modifications.

This still includes the FakeCache correct implementation, sorry if it mixes up with the other related issue, but it's simpler this way.

Personal reminder: need to separate the null object cache implementation and put in the right issue: #1082328: Provide a proper no-op cache.inc

Done, and waiting for it to be commited to fix the patch here.