You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Similar to the questions posed in whatwg/storage#88, would it be helpful to have a .clear() method (get rid of contents, but bucket remains) in addition to .delete()? As far as I can tell, this essentially boils down to: "do we want to be able to persist the bucket options/metadata even when the contents are deleted?"
The text was updated successfully, but these errors were encountered:
We want applications to be written assuming that each time they attempt to open a bucket, they may be creating the bucket from scratch.
(The reasoning here is that via automatic eviction or manual clear browsing data, the bucket could be deleted at any time and the app must expect that to happen.)
If authors are truly writing their code with this assumption, then they should always be specifying all the metadata about the bucket in the open call. If they do that, then there's little difference between clear and delete (just what's returned by the keys function between clear/delete and the next open). So I vote for no clear method.
I guess the other difference would be what happens to the bucket or a storage type handle (such as the caches object) after delete() or clear() is called.
Similar to the questions posed in whatwg/storage#88, would it be helpful to have a
.clear()
method (get rid of contents, but bucket remains) in addition to.delete()
? As far as I can tell, this essentially boils down to: "do we want to be able to persist the bucket options/metadata even when the contents are deleted?"The text was updated successfully, but these errors were encountered: