delete_many stop at first error about flask-caching

[sh4nks]

Looks like it's our problem now :P

[sh4nks]

this is a problem with werkzeugs filesystem cache problem and not a flask-caching ones.

as you can see here, delete_many is just a proxy function to the underlying backend.

[johaven]

That's right I report on the werkzeug side

[buckley-w-david]

@sh4nks I'll take a go at this issue, but before I do it's probably a good idea to discuss what the desired behavior is.

Right now the behavior of the delete_many method is actually inconsistent, in the cases where the cache just uses the inherited delete_many, the evaluation short circuits on a failure as this issue describes, but on classes that have overridden the method it'll be down to how it's implemented.

It's pretty simply to just change the delete_many method in the BaseCache to not short circuit, but the question is that this is actually a potentially breaking change, as it is possible that some user of the library is relying on this behavior.

That suggests that the addition of the ignore_errors=False flag to the method is a good one to resolve this, as it would allow the improved behavior without risking breaking existing implementations, but that has some strange implications on other cache objects (Like Memcached, that uses the underlying batch delete method to improve performance) of also having to honor the flag.

Do we consider the short circuit behavior a bug? It is unspecified behavior, so people really shouldn't have been relying on it. If we do consider it a bug, we wouldn't have to worry about the additional overhead of new deletion logic and impacting the performance of specialized delete methods.

[sh4nks]

@buckley-w-david sorry for my late response - I am very busy with uni stuff and have barely time to maintain my personal projects.. anyway, if you are still interested - go for it! :)

I like the idea of adding a ignore_errors=False flag but I don't understand why there would be any implications if it is by default False?

I do, however, consider it a bug so we wouldn't have to worry about new deletion logic etc. I think this might even justify a major version pump to 2.0.

[buckley-w-david]

No worries, I'm in the same boat.

The issue I was thinking of back then I think was that since each of the cache's current behavior is inconsistent (some stop on first error some don't), just throwing in a ignore_errors=False would change existing behavior, for example the memcached cache is implemented via a batch command and so doesn't suffer from the stopping early bug.

What I didn't think of at the time was that each of the methods could just be given the default value to match their current behavior, which resolves that.

[sh4nks]

Hehe. Yeah, then lets do it this way :)

[johaven]

with a little delay, thank you :)