Entries movement between caches

[NekR]

I have a such situation:

One primary cache, let's call it static. This cache always exists, never changes name and only entries in it are changed. Difference is found by comparing two maps 1) existing, described currently cached entries; 2) new, which came with a newly generate SW (new build). Difference is computed on install event and new assets/files are stored in tmp cache. Then, on activate event, old assets are deleted from static cache or simply overridden by new version (if file name/url wan't changed).

My question, can we have some fastest way to import entries from one cache to another? Because as far as I understand, reading from one cache and writing to another is kind of slow and not "looking good" operation.

[NekR]

Just saw this comment: #867 (comment)

Yes, something like that!

[jakearchibald]

Closing as a dupe, reopen if I'm wrong

[wanderview]

FWIW implementations can be smart about this and detect that a Response from the same CacheStorage is being put back into. In this case the browser can avoid re-writing the body.

But yea, a more/rename would be nice.

Edit: And I plan to do that eventually in gecko when this is implemented: https://bugzilla.mozilla.org/show_bug.cgi?id=1110479

[NekR]

Closing as a dupe, reopen if I'm wrong

Dupe of what? Would be good to know it, so I could track that issue. Or if you meant dupe of that comment, then I referred to a comment in not-related issue.

FWIW implementations can be smart about this and detect that a Response from the same CacheStorage is being put back into. In this case the browser can avoid re-writing the body.

I thought about it, but without a special function exactly for that we have to convince all implementations to have such optimization.

[jakearchibald]

Are you happy with caches.move(oldName, newName) as a solution? If so I'll rename the title

[NekR]

@jakearchibald it's not about renaming caches (which would be good to have by itself), but about moving individual entries of cache A to cache B. Something like this: cacheA.move('/main.js', cacheB) (but better version)

[jakearchibald]

I think we should look at transactions before providing more high-level cache manipulation APIs. The stuff in your OP is possible today, right? You can take something out of one cache and put it in another.

[NekR]

@jakearchibald yes, possible and I do not insist that it's 'you must do it immediately'. Just left it here as 'would be good to have'.

Also, it's probably not a high-level API since, just an abstraction over 'move reference of this object in DB from this cache to this cache'. Something what we cannot do today: manipulate cache references.

[wanderview]

I don't think the spec should mandate optimizations or perf for something like this. The API provides a way to take something from cache A and put it in cache B. Its flexible enough for implementations to optimize. I don't think we should tie implementation's hands by prematurely forcing an optimization here.

[NekR]

Sounds reasonable. Anyway, would be good to have this API.
In the meantime, does it makes sense to open specific issues in Firefox/Chrome bug trackers with 'please optimize cache entries movement because this is my use case' ?

[wanderview]

You could write bugs like that, but it would be interesting to know if its slow in the first place. Unless you are moving extremely large files its probably not noticeable.

[NekR]

I do not know how slow it's, but I can imagine slow old HDDs where each operation is slow operation.