Re: [w3c/IndexedDB] Backward-compatible schema changes are very hard (#282)

Here's one potential solution:

Add a new "schemachange" transaction type. The scope of the "schemachange" transaction would always be the whole database, which means that two "schemachange" transactions can't run in parallel (this could be somewhat relaxed, but let's start simple).

When a "schemachange" transaction is committed, it updates the list of objectStores and indexes only of the current IDBDatabase object. Any other open IDBDatabase object will not get an updated list of objectStores or indexes. However any attempt at reading or writing from a objectStore or index that non longer has changed, or which doesn't have a "compatible schema" will result in a failed request.

A "compatible schema" for objectStores means has the same value for `keyPath` and `autoIncrement` flag. For an index it means that the index's objectStore has a "compatible schema". (We could tighten the requirement for indexes to require that they have the same `keyPath`, `unique` flag, and/or `multiEntry` flag, but it doesn't seem strictly necessary)

One unfortunate aspect is that the function to create a "schemachange" transaction has to be asynchronous. I.e. it can't synchronously return a `IDBTransaction` object. This is because it must return an `IDBTransaction` object with an up-to-date list of objectStores and indexes so that the page can check if the neccessary changes have already been done.

So the only needed changes in the API would be
* Add `"schemachange"` to `IDBTransactionMode`
* Add a new function similar to `transaction`, but which is async and doesn't take any arguments


This effectively creates a separate method of handling schemas where the webpage takes on the responsibility to handle schema versioning, rather than the current one based on version/onupgradeneeded/onblocked/onversionchange

To make this method safer we could say that you're only allowed to *add* objectStores and indexes during a "schemachange" transaction. Not remove objectStores or indexes, and not change any existing data. But I think that partially defeats the purpose of adding a "I know what I'm doing" API.

I think it'd be more interesting to add API surface to enable a page that wants to use "schemachange" transactions to avoid having to use version/onupgradeneeded/onblocked/onversionchange when they open the database the first time. Possibly by simply allowing 0 to be passed a version to `IDBFactory.open`.

-- 
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/282#issuecomment-643829882