IndexedDB data retrieval by key stops working if an existing database is upgraded to iOS 10.3. For example, for a table that has a numeric primary key and a unique string secondary key, attempts to retrieve records either by the primary key or the secondary key return undefined. I was able to determine that the data itself is still there by doing a retrieval of all data. The fields that are used as keys have values, but I don't know what the state of the key structures themselves is, whether they are gone or pointing to the wrong place now. I'm using Dexie so I can't give you the native indexedDB syntax, but it's easy to reproduce. If the database is created under iOS 10.3, there isn't a problem. It's something happening in the upgrade.
<rdar://problem/31393946>
(In reply to Meredith Anderson from comment #0) > IndexedDB data retrieval by key stops working if an existing database is > upgraded to iOS 10.3. For example, for a table that has a numeric primary > key and a unique string secondary key, attempts to retrieve records either > by the primary key or the secondary key return undefined. I was able to > determine that the data itself is still there by doing a retrieval of all > data. The fields that are used as keys have values, but I don't know what > the state of the key structures themselves is, whether they are gone or > pointing to the wrong place now. I'm using Dexie so I can't give you the > native indexedDB syntax, but it's easy to reproduce. If the database is > created under iOS 10.3, there isn't a problem. It's something happening in > the upgrade. There's definitely a new storage format for keys on disk, but we also definitely handle the only key format. I can demonstrate with a simple local test case that we do handle legacy key lookups fine. Even though you saw this with Dexie and therefore don't have the raw IDB, can you please include a minimal Dexie test case? I can find out the raw IDB from that.
Created attachment 306173 [details] Test case using db.js indexeddb adapter This same issue has happened to me, using the db.js adapter. Based on the test case (attached), it looks like all of the table data is wiped if the table is set to NOT autoincrement ids. The other tables DO keep their data across the udpate. I have not found a way to retrieve the lost data after the update. In earlier versions of Safari, the autoincrement functionality was buggy, so many app developers worked around it by using their own IDs. The next step would be to test a non-autoincrement table using vanilla js.