Optimize checkForCacheUpdate to avoid deleting the same cache key multiple times

[LoLei]

Description

In some installations, the same cache key may be multiple times in the cache_rebuild table. Therefore, the same DELETE statement will be executed multiple times, even though it would only be necessary to be executed once, to delete that key from the table. (E.g. DELETE FROM cache_rebuild WHERE cache_key='app-metadata-theme-images'). This change optimizes the loop that iterates over the keys to be deleted, and keeps track of those keys already deleted, to skip any additional superfluous deletions.

Motivation and Context

In our installation, the app-metadata-theme-images cache key was over 200k times in the cache_rebuild table. Therefore, the DELETE FROM cache_rebuild WHERE cache_key='app-metadata-theme-images' was also executed that many times, on the first login of the day, in the appMetaData GraphQL request.

How To Test This

Duplicate the same cache key multiple times in the cache_rebuild table. checkForCacheUpdate should now only call the corresponding deletion once, instead of multiple times. (Set $sugar_config['logger']['level'] = 'info'; to see executed queries in the SuiteCRM log.)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Final checklist

• My code follows the code style of this project found here.
• My change requires a change to the documentation.
• I have read the How to Contribute guidelines.

[SuiteBot]

All committers have signed the CLA.

[chris001]

Should that cache_key be made part of the primary key, so that a record containing it can only occur once, and not need any application code to enforce that the record be unique, and that the deletion of the cache key can then only occur once.

[LoLei]

@chris001 Not sure I fully understand your comment. Is this something I can adapt in my PR, or are you thinking in a more theoretical / broader sense?

[chris001]

Broader sense. If the cache_key were part of the primary key, this would not be an issue!