On 06 Apr 2011, at 6:49 PM, Shawn Wilsher wrote: > On 4/4/2011 10:18 AM, Joran Greef wrote: >> How would you create an index on an existing object store in IndexedDB >> containing more than 50,000 objects on an iPad, without incurring any object >> deserialization/serialization overhead, without being an order of magnitude >> slower than SQLite, and without bringing the iPad to its knees? If you can >> do it with even one IndexedDB implementation out there then kudos and hats >> off to you. :) > You keep bringing this point up, but only a naive implementation of IndexedDB > would bring a device to it's knees (or a poorly implemented thread scheduler, > which I don't expect the iPad to have). The API is asynchronous, which means > it doesn't need to (nor should it) happen on any thread that the UI is being > drawn on. > > You still have a point about it possibly taking longer, but even then, that > will be implementation dependent. > > Cheers, > > Shawn >
I bring up the iPad example because I had experience with a LocalStorage implementation (I think it was Safari) loading the contents of LocalStorage into memory synchronously on first access, blocking the UI thread. I am probably wrong on this one but I think I remember reading on Web Apps that this was one of the motivations behind limiting LocalStorage quota to around 10mb. At the time I was one of those who believed that LocalStorage would support storage of at least 10 GB as a matter of course. I hope you can understand my slight distrust of subsequent storage APIs (other than those of proven track record) in this light. It would still take longer (easily 30-50 seconds per 50,000 objects more than an opaque key-value store built on SQLite) even if the IndexedDB implementation was asynchronous. The developer would also have a tough time reasoning about when index migrations would be finished, since IndexedDB offers no control over the migration process and provides no way to modify index memberships directly. For those that care about these things, IndexedDB does not provide sufficient low-level storage primitives.
