<html>
<head>
<base href="https://bugs.webkit.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - IndexedDB keys are gone or nonworking after upgrade to iOS 10.3"
href="https://bugs.webkit.org/show_bug.cgi?id=170358#c2">Comment # 2</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - IndexedDB keys are gone or nonworking after upgrade to iOS 10.3"
href="https://bugs.webkit.org/show_bug.cgi?id=170358">bug 170358</a>
from <span class="vcard"><a class="email" href="mailto:beidson@apple.com" title="Brady Eidson <beidson@apple.com>"> <span class="fn">Brady Eidson</span></a>
</span></b>
<pre>(In reply to Meredith Anderson from <a href="show_bug.cgi?id=170358#c0">comment #0</a>)
<span class="quote">> 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.</span >
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>