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

On 06 Apr 2011, at 8:56 AM, Jonas Sicking wrote:
> 
>> 1. Treat object values as opaque (necessary to avoid deserialization/serialization overhead, this is mandatory for storing anything over 50,000 objects on a device like an iPad or iPhone).
> 
> Please explain this in more detail as I have no idea what you mean by
> "treat as opaque". Are you saying that we should not allow storing
> objects but rather only allow storing strings? If not, surely any type
> of object needs to be serialized upon storage. If you are simply
> suggesting forbidding storing objects, then this doesn't seem like a
> blocker. Simply store a string and we won't serialize anything.
> 
> I'm also interested in what you are basing the claim on overhead on.
> Have you profiled a IndexedDB implementation? If so, which? And if
> Firefox, did you do so before or after we switched away from using a
> JSON serializer?

Yes, it must accept a string value and store that directly. The "opaque" terminology comes from some of the BDB papers.

I tested both Chrome and Firefox implementations 3 weeks ago. Both were an order of magnitude slower than using SQLite as a key-value store (storing strings as blobs). You can use whatever serializer you like, but it will always be slower than avoiding serialization completely (this is possible by the way, my application does not deserialize objects received from the server before storing them). Even if your serializer takes only 1ms per serialize call, that's 50 seconds for 50,000 objects. For my use-case that is unacceptable, considering that SQLite is available in Chrome and Safari. I will encourage my users to use those browsers and continue developing for SQLite until IndexedDB resolves this issue.

How would you support indices (see below) if you say "Simply store a string and we won't serialize anything."?

>> 2. Enable indices to be modified at time of putting/deleting objects (index references provided by application at time of putObject/deleteObject call).
> 
> I don't believe that this is a blocker. You can simply modify the
> object you are storing to add properties and then index of these
> properties. What you are suggesting only has the advantage that it
> allows storing objects without modifying them. While that can be
> important, it isn't a blocker to at least creating a prototype
> implementation.

How would you index objects passed to putObject as a string (see above)? Plus you have the unnecessary object creation overhead. How fast is it to create 50,000 objects on an iPad? What would that do to the GC and why would you want to do that if you don't need to?

I would like to see Mozilla "do as they say": re-implement a SQLite on IndexedDB themselves, that is just as fast and memory efficient as the original, before suggesting that this is possible, that the web therefore be deprived of SQLite. Furthermore, that Mozilla stop using SQLite for all internal use, and rely solely on IndexedDB instead. That is essentially the request that Mozilla are making of web developers today.

It's clear that scores of web developers are upset with the decision to deprecate WebSQL. It's not clear that IndexedDB provides anything close in terms of actual raw performance. This surprised me greatly since I assumed IndexedDB would naturally leverage established indexed key-value ideas (for instance to quote BDB - "In Berkeley DB, the key and value in a record are opaque to Berkeley DB") which would give it an edge over SQLite.

Pragmatically speaking, would it really be so hard for Mozilla to join Chrome, Safari and Opera and provide an embedding of SQLite along with IndexedDB?

If IndexedDB is as good as you suggest it is, then I am sure developers will flock to it, and you won't need to speculate as to whether or not SQLite will take over the web and then break backwards compatibility (despite a stated objective and proven track record of not doing so). And if SQLite did ever break backwards compatibility then developers would have IndexedDB. And if applications relying on SQLite are abandoned by their authors and broken as a result of not upgrading, then arguably those applications should be deprecated and not SQLite.

Received on Wednesday, 6 April 2011 10:21:47 UTC