kaizhu256
commented
4 years ago related but off-topic,
chrome limits each key's value to ~240MB. which in turn limits the size of persistable wasm-objects (e.g. a wasm-sqlite database).
Open pwnall opened 4 years ago
kaizhu256
commented
4 years ago related but off-topic,
chrome limits each key's value to ~240MB. which in turn limits the size of persistable wasm-objects (e.g. a wasm-sqlite database).
pwnall
commented
4 years ago @kaizhu256 How about filing a bug at https://crbug.com/new explaining your situation? I'm curious to learn why you need large keys.
Starting in Chrome 84, we've significantly improved how we handle large values. Based on what I know about databases used as backing stores for IndexedDB, I'm hoping to drive the web ecosystem towards small keys, where "small" means at most kilobytes in length. This is because keys show up in indexes, and key length directly impacts the performance of all database operations.
kaizhu256
commented
4 years ago Sorry, I meant the value mapped by key. Key-length of 1kb is fine ^^;;;
inexorabletash
commented
4 years ago Nit: Maximum recursive depth of arrays/objects in an IndexedDB key
Only arrays, since objects aren't a valid key type.
apsiriwat
commented
3 years ago
IndexedDB implementations may have limits on keys. These limits may come from the underlying storage system (perhaps the underlying database has a limit on index key sizes) or from a desire to preserve system stability and performance.
We should expose limits in existing implementations, to facilitate feature detection in this area. Sites can use alternate code paths or disable features based on the limits.
To kick things off, here are two limits from Chrome that I would like to expose, together with proposed API.
IDBKeyRange.maxArrayLength- Maximum length of an array used in an IndexedDB key. This is currently 1,000,000 in Chrome.IDBKeyRange.maxDepth- Maximum recursive depth of arrays in an IndexedDB key. This is currently 2,000 in Chrome.