jensarps/IDBWrapper

IE always asks to bump dbVersion again

Closed this issue · 4 comments

We're experiencing the following in Internet Explorer 11 on Windows 8.1. We're creating an IDBStore with the following config:

var IdbWrapper = require("idb-wrapper"); // we're using npm and browserify

new IdbWrapper({
  "storePrefix": "XX-",
  "dbVersion": 2,
  "indexes": [{"name":"user.id","keyPath":"user.id","unique":false,"multiEntry":true}],
  "keyPath":"activityId",
  "storeName":"activities"
});

We bumped the dbVersion to 2, because this is the first time we're changing the schema by adding an index to this database. In Internet Explorer now the following happens: We clear all IndexedDB files through the Settings, then refresh the application in the browser, click through functionality that uses this database, everything is fine. Then we refresh the application again, and this time, when the IDBStore is initialised, we get the following error:

ERROR initializing idbWrapper
Cannot modify index "user.id" for current version. Please bump version number to 3."

If we then bump the version to 3, the same thing happens again, after second refresh it asks us to bump to 4, etc.

Any idea why this might be happening?

Thanks a lot.

Thanks for reporting!

That happens because IE 11 still doesn't support multiEntry indexes (as well as compound indexes).

IDBWrapper compares the actual indexes with the ones given in the constructor; if they don't match, it asks to bump the version number to be able to create them during an "upgrade" of the database. That's why it runs smooth on the first run; IDBWrapper calls the API for creating the index, which does not report errors. On the second run, it detects the same mismatch again and complains.

This is nothing I can fix; however, I recently stumbled upon this: https://github.com/dfahlander/idb-iegap

It claims to polyfill the gap IE has regarding indexes – maybe it's worth giving a shot? If you do, please tell me if it worked for you.

I'll leave this open, as there are no tests for multiEntry, but there should be.

Hm, just a quick question: Are you sure about user.id needing a multiEntry index? I mean, is user.id an array? Sorry for asking that, I don't know your data structure, it's just that the property doesn't look like it's containing an array.

To be honest, we did not fully get the meaning of multiEntry... So when we were testing this on our machine (Chrome/Firefox on Mac), we weren't really seeing the difference and I guess we left that setting in, and then later when it was running on IE in our test setup we did not think to change the multiEntry thing again :-)

So thanks a lot for the pointer, we'll try that!

Closing this, as there now tests for multiEntry.