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

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

So now getAll() should be preferred over cursor?
How is MongoDB getting all the data then? Why is MongoDB this much faster than IndexedDB, shouldn't indexedDB be as fast as Redis? Redis and IndexedDB use key:value pairs and are a key value storage. Other way would be to use the ID and get IDs in range but then it would still need a cursor, so it's a dead end.

> 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.

This might be true, but the cursor seem to slow compared to getAll(), isn't there a faster way to search through the objectStore? IndexedDB has it's own DB engine right? So why isn't the cursor written in low level like C and would store the values in BSON?

Also thank you for your time willing to reply

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

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