W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: [WebSQL] Any future plans, or has IndexedDB replaced WebSQL?

From: Joran Greef <joran@ronomon.com>
Date: Wed, 6 Apr 2011 19:06:50 +0200
Cc: public-webapps@w3.org
Message-Id: <CD333F6D-A394-48E1-8BA1-5779202D7F8F@ronomon.com>
To: Shawn Wilsher <sdwilsh@mozilla.com>
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.
Received on Wednesday, 6 April 2011 17:08:13 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:44 GMT