What happens when the polyfill is no longer needed?

[dumbmatter]

First of all, this is a really cool project, thanks for your work!

Now, let's imagine some crazy parallel universe where Microsoft decides to implement compound and multientry indexes and they push it as an automatic update to their users. What happens then? Am I going to run into weird incompatibility problems with new/old users or have to do some kind of complicated IndexedDB database upgrade or something?

[dfahlander]

No, it would still work but not be optimal. Currently I just check the user
agent to know whether it's needed. Saw this post
http://stackoverflow.com/questions/26769265/feature-detection-of-buggy-indexeddb-implementations
yesterday which would probably be a better check.

David Fahlander
Awarica AB
Selmedalsvägen 24, 8tr
12936 Hägersten
Sweden
Växel: 08 525 041 90
Mobil: 070 789 14 07
Webb: www.awarica.com

2014-12-02 3:31 GMT+01:00 Jeremy Scheff notifications@github.com:

First of all, this is a really cool project, thanks for your work!

Now, let's imagine some crazy parallel universe where Microsoft decides to
implement compound and multientry indexes and they push it as an automatic
update to their users. What happens then? Am I going to run into weird
incompatibility problems with new/old users or have to do some kind of
complicated IndexedDB database upgrade or something?

—
Reply to this email directly or view it on GitHub
#2.

[dumbmatter]

Regardless of whether you do feature detection or user agent checking to identify buggy clients, you still have to eventually deal with a buggy client that gets upgraded to a non-buggy version. So if IE12 is released and it supports all this stuff, it will pass your check and your polyfill won’t be applied. Great for new users, but for someone upgrading from IE11, they’ll still have index data stored in your metadata tables and they won’t have the real indexes for their object stores, so it’ll break (please correct me if I’m wrong).

If this is the case, I think you need to do two things:

1. Store some marker of whether your polyfill was originally used when creating an object store or not. If the marker is set, always use your polyfill for that object store, even if the browser supports array indexes.
2. Provide some upgrade path for these users if they upgrade to a non-buggy browser. At a minimum, have some function to check if it’s a non-buggy browser but the object store was originally created with your polyfill, so the user could manually run that in onupgradeneeded and create the real array indexes if necessary. And also have some other function to disable your polyfill for an object store (delete the marker described in Fails in upgrade unit test for Dexie.js #1) so the real array indexes would actually be used.

If that sounds reasonable, I could give it a shot some time soon... I was about to release an update to this that uses compound indexes to improve performance, but I'd rather not lose the 5% of my userbase that is on IE10/11.

[dfahlander]

You are sooo true! This is super important stuff . Another (less but still important) use case I want to deal with is upgrading existing DBs from non-polyfilled to polyfilled.

Will keep this issue open until both these aspects are solved.