Re: [w3c/IndexedDB] Why is IndexedDB this bad? (Issue #369)

> decided to add cursors that are slower than simply getAll() and looping through everything

getAll() was added after cursors; getAll() also required unbounded memory in the general case, so asynchronous iteration is a necessary primitive.

> I rather use IndexedDB as a simple store to getAll() and throw everything into LokiJS where I'm able to do queries and actually work with the data.

Great - if that's working for you, then IndexedDB's design is effective. The intention (predating my involvement) was to provide a low-level key value store on which to build more expressive storage engines.

> why is it blocking the main thread

It's not, which is why all requests are asynchronous, returning an IDBRequest and signaling completion using events.

> but this could have been something like Promises

IndexedDB predates Promises. Like most problems on the Web Platform, this could be solved with a time machine.








-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/369#issuecomment-998182413
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/369/998182413@github.com>