Add `delete_multi` method to cache

[peterzhu2118]

Summary

Adds ActiveSupport::Cache::Store#delete_multi to delete an array of keys from the cache.

For most implementations, this just calls ActiveSupport::Cache::Store#delete n times, but Redis supports deleting an array of keys. This can improve performance because it turns what is previously n delete calls into a single call.

Memcached does not support multi delete.

[jeremy]

Nice feature! Observe the interaction between read_multi (public API implemented once in base class) and read_multi_entries (private implementation; default in base class, overridden in subclasses). You can follow this pattern with delete_multi (public API) and delete_multi_entries (private implementation) as well.

[peterzhu2118]

Hey @jeremy, thanks for the review! I've updated the implementation with your suggestions, please take another look!

[peterzhu2118]

Hey @jeremy, could I get another review please?

[jeremy]

Should we introduce this requirement? Redis naturally returns the number of entries deleted, but it may be costly or impractical for other cache stores.

[peterzhu2118]

The regular delete_entry returns a Boolean on whether it successfully deleted an entry or not, so I don't see why this would be more costly since for most cache stores it just calls delete_entry n times. Is there a particular cache store you think could get a performance bump if this requirement was dropped?

[jeremy]

We are introducing a new API. Do we care about its return value, or should we leave it undefined?

For example, consider a third-party cache store that supports batch deletes but doesn't report the number of actual deletions. Or a cache store that issues deletions asynchronously. Should these implementations attempt to return a count of deleted entries?

[peterzhu2118]

Thanks for the explanation! I've updated it to keep the current logic but removed the return value from the documentation.

[jewilmeer]

Awesome! We used a custom implementation and can now switch back to the default again! Thanks @peterzhu2118

[n-rodriguez]

it it the good assertion here?