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

On Wed, Apr 6, 2011 at 3:21 AM, Joran Greef <joran@ronomon.com> wrote:
> 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.

This is already supported, so I don't understand why you list this as
a blocker for implementing something like RelationalDB.

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

Sounds like you have no basis for saying that serialization is an issue then.

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

This however is a problem I agree. However shouldn't be a blocker for
RelationalDB. You'd simply get a bit of overhead. In fact, writing a
prototype would allow us to measure how big that overhead is and would
make an excellent case for adding the API you are suggesting.

/ Jonas

Received on Wednesday, 6 April 2011 14:40:04 UTC