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

On Tue, Apr 5, 2011 at 9:33 PM, Joran Greef <joran@ronomon.com> wrote:
> On 06 Apr 2011, at 2:53 AM, Pablo Castro wrote:
>
>> The goal of IndexedDB has always been to enable things like RelationalDB and CouchDB to be built on top, while maintaining a reasonable level of functionality for those that wanted to use it directly. I really like the idea of thinking of RelationalDB as something that's built as a library on top of IndexedDB. Are there specific tweaks we can make to IndexedDB so it can be a good lower-layer for RelationalDB, such that RelationalDB could be built as a pure JavaScript library?
>>
>> Thanks
>> -pablo
>
> 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?

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

> 3. Provide a simpler, more powerful locking mechanism, opaque to IndexedDB, to provide finer-grained application-specific locking (i.e. have we just entered into a sync process with the master database).

Are you talking about supporting row-level locking? As far as I can
tell we support as fine grained locking as possible without going to
row-level locks. We already support more fine grained locking than for
example WebSQL which only support whole-database locks.

None of the issues you are listing seems like blockers for creating a
RelationalDB implementation on top of IndexedDB. And there's still an
abundance of lack of proposals.

/ Jonas

Received on Wednesday, 6 April 2011 06:57:20 UTC