WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
170358
IndexedDB keys are gone or nonworking after upgrade to iOS 10.3
https://bugs.webkit.org/show_bug.cgi?id=170358
Summary
IndexedDB keys are gone or nonworking after upgrade to iOS 10.3
Meredith Anderson
Reported
2017-03-31 14:03:51 PDT
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.
Attachments
Test case using db.js indexeddb adapter
(8.60 KB, application/zip)
2017-04-04 07:32 PDT
,
Andrew
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2017-04-02 11:16:10 PDT
<
rdar://problem/31393946
>
Brady Eidson
Comment 2
2017-04-02 18:04:08 PDT
(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.
Andrew
Comment 3
2017-04-04 07:32:16 PDT
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.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug