Named areas/versions/upgrades about kv-storage HOT 4 CLOSED

Ah, thank you; my extrapolation from https://github.com/jakearchibald/idb-keyval/blob/master/idb-keyval.js definitely doesn't work in this case.

Would you mind dropping the code you would suggest (in JS, presumably) for the kind of API we're trying to create here? I.e. at what point should we create the store? Alternately I can look it up myself if you're busy.

from kv-storage.

I think the easiest thing to do is use a single fixed store name so you never deal with upgrades, and use a compound key.

i.e. instead the guts of get() become:

        const transaction = this.#connection.transaction("store", "readonly");
        const store = transaction.objectStore("store");
        const request = store.get([key,this.#storeName]);

Where "store" is a Well Known Name in the API's use of IDB just like "async-local-storage"

This means certain operations (e.g. clear(), keys(), etc) become explicit range operations, which is unfortunately tricky given a lack of prefix ranges.

from kv-storage.

Hmm, I'm not sure that sounds so easy :-/.

Maybe instead we should use a single fixed store name, but a separate database per StorageArea?

from kv-storage.

Yep, that'd work too. More overhead per area but that's an implementation's problem to optimize.

from kv-storage.