Indexed DB: Fix compound index keys vs. autoincrement stores
Stores with (1) a keyPath (a.k.a. inline keys) and (2) autoIncrement (a.k.a. a key generator) have primary keys generated by the browser and inserted into objects lazily, since the renderer doesn't know what the primary keys will be when the object is serialized. Indexes might have a keyPath that references the same spot in the object. This is handled by checking if the keypaths match. If so, the browser synthesizes the index key (same as the primary key). But Chrome was not handling the case where the index had a compound key - a keypath that's an array, plucking multiple values out of the object. An object with unresolved keypaths would normally just not be indexed, per spec. But since the primary keys should be injected before the indexing occurs, these should be indexed. Fix this by sending the index keys from the renderer to the browser as an array with "holes" that need to be filled in. This is covered by an existing Web Platform Test, which we now pass. Bug: 701972 Change-Id: I14940b23cfcbb7f8b673143b402f574220184fd7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1728058 Commit-Queue: Joshua Bell <jsbell@chromium.org> Reviewed-by:Kenichi Ishibashi <bashi@chromium.org> Reviewed-by:
Chase Phillips <cmp@chromium.org> Cr-Commit-Position: refs/heads/master@{#692313}
Showing
Please register or sign in to comment