Named areas/versions/upgrades

[inexorabletash]

The steps/code in 3.1 seem to misunderstand how versioning and schema works in Indexed DB. upgradeneeded only fires if the version changes. So:

new StorageArea('a'); 
// opens 'async-local-storage' at version 1, which didn't previously exist
// runs upgradeneeded, creates store 'a'


new StorageArea('b');
// opens 'async-local-storage' at version 1, which previously existed
// upgradeneeded does not fire

So store 'b' will never be created

[domenic]

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.

[inexorabletash]

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.

[domenic]

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?

[inexorabletash]

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