IndexedDB error adding new model type

[chbonser]

Overview

In development after I add a new model type, then load it via a remote store the following error occurs.

Deleting the IndexedDB database and reloading resolves the issue.

Config

Sources

• remote: jsonapi
• backup: indexeddb

Strategies

• SyncStrategy: remote -> store (blocking)
• SyncStrategy: store -> backup (non-blocking)
• RequestStrategy: (on beforeQuery, query) store -> remote (blocking)
• RequestStrategy: (on beforeUpdate, update) store -> remote (blocking)

Note: I'm not actually doing anything with the backup yet but I plan to use it to enable an offline mode later. Note 2: This is a brand new app and I don't have any code yet that would trigger the beforeUpdate strategy to see if it causes the error too.

Versions

ember-orbit@0.17.0-beta.14 @orbit/indexeddb@0.17.0-beta.22 @orbit/jsonapi@0.17.0-beta.22 @orbit/serializers@0.17.0-beta.19

[dgeb]

I would guess that what's happening here is that you're fetching all records (findRecords()) from backup prior to coordinator activation. A new record type has been added to the schema prior to this action, so the schema knows about the type but the backup source does not yet. It attempt to look up an objectStore for this type but it does not (yet) exist.

The way to handle this with IndexedDB is through versioning. Every time that you open an IDBDatabase, you can optionally specify a version.

Orbit also supports a version on its RecordSchema. This property is used by default as the version for the IDBDatabase. When an old version of the DB is opened with a new version (say, after your app has updated), you have the opportunity to migrate the contents of the DB in the browser. You can do this by overriding this method on the IndexedDBCache.

You can control upgrades by calling schema.upgrade({ version: 2 }) and all the sources that care will listen to this event and attempt to upgrade their contents prior to any data access.

This can be a bit of a hassle and probably only something to tackle when you have instances of your DB "in the wild". When you do, you'll want to keep track of what changes between versions so that you can write migrations. In this case, you'd just want to call registerModel to add a new objectStore for the new type. Many changes, such as new fields that are not indexed, won't really require new versions or migrations.

Anyway, sorry for the confusing error message. This area deserves some better documentation.

[chbonser]

In this case I am not calling findRecords on backup at all. I'm sync'ing to the backup and then doing nothing with it. I plan to do so but wanted to have a few areas of the app working before I mixed in booting offline.

The info about versioning makes a lot of sense though and I'll plan to handle that when I revisit offline mode.

If you think this is related to my lack of handling of versioning then we should close this ticket.

[dgeb]

If you are sync'ing to the backup and adding records to an object store that does not exist, then this error could be raised. I will see if I can minimize versioning exceptions by simply detecting and creating object stores when they don't already exist, without requiring an explicit version upgrade.

[dgeb]

I will see if I can minimize versioning exceptions by simply detecting and creating object stores when they don't already exist, without requiring an explicit version upgrade.

Turns out that object stores can only be created inside versionchange transactions, which can only be handled by opening an IDB with an updated version. Therefore, I can't make this truly seamless, even in development.

PR #362 adds a schemaVersion config option that will be passed to the orbit schema on construction. Bumping this version should trigger a versionchange transaction, which will run the migratedDB method on IndexedDBCache as I mentioned above. Override this method to provide custom migrations.

Of course, this is really only relevant when you have production IDB instances in the wild. As you work in development, it's easiest to just delete your local IDB instances as you add models and adjust your schema.

Please let me know if you have further questions and I can re-open this issue if needed.