Re: [w3c/IndexedDB] Allow more explicit control over transaction lifetimes (#34)

I'd like to give my real-world example of how pain is it to use Indexed DB v2.

I have a database called `crypto-keys` than contains WebCrypto CryptoKeys object, let's assume it is in version 1.

In version 2, I need to change from `CryptoKey`s to `JsonWebKey`(a plain object) but I can't do it in the upgrade transaction, because in the WebCrypto spec, export a `CryptoKey` to `JsonWebKey` is an async operation.

Even worse, in Indexed DB v2, I can't query the database version (it's a v3 API and only Chrome support it now) so I can't open the current version (1) based on the query result and prepare all async data I need, then open the database in version 2 to use previously prepared data to move from 'CryptoKey` to `JsonWebKey`.

In the end, I have to open my database like this: (and I think this kind of solution is very, very ugly)

![image](https://user-images.githubusercontent.com/5390719/79097751-138e9f80-7d93-11ea-90b6-09f5c68bd3af.png)

0. Set `UpgradeData` to undefined
1. Open the database of version `firstVersionThatRequiresAsyncUpgrade` (might fail cause DB version might be greater than that) with `UpgradeData`, if failed, goto step 4
2. If `firstVersionThatRequiresAsyncUpgrade === latestVersion`, return the db, it is upgraded asynchronously to the latest version
3. Run the `asyncUpgradePrepare` for database, set result to `UpgradeData`
4. `firstVersionThatRequiresAsyncUpgrade++`
5. Go to step 1

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/34#issuecomment-612773400

Received on Monday, 13 April 2020 06:36:01 UTC