W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: [IndexedDB] Synchronous access to object stores

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 26 Mar 2012 13:44:46 -0700
Message-ID: <CA+c2ei904WAZ99_f7WVAOVCB8hJ7NADHn7ktmwfNoSdDBoPdNw@mail.gmail.com>
To: Joćo Eiras <joaoe@opera.com>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>
On Mon, Mar 26, 2012 at 5:07 AM, Joćo Eiras <joaoe@opera.com> wrote:
>
> Hi.
>
> After a open database request, going from the IDBDatabase to the
> IDBObjectStore's properties is synchronous, which means that either all the
> metadata for every object store has to be preloaded, or that the ecmascript
> engine needs to wait (therefore blocking the page) while the request is done
> in the background.
> The first issue raises the question: what if there are 10 000 object stores
> ? Preloading everything is overkill. The second issues raises another
> question: blocking for file IO ?
>
> var r = indexedDb.open('foo');
> r.onsuccess = function(){
>  r.transaction('o').objectStore('o').indexNames;
> }
>
> Supporting this is a trivial implementation detail, but the spec has the
> issue nonetheless.

The idea is to keep all of the index and objectStore meta-data in
memory. Yes, this could potentially mean keeping information about
10000 object stores in memory, but that doesn't seem very different
from how the synchronous nature of the Node API could force you to
keep 10000 text nodes in memory.

Creating lots of object stores or indexes is generally going to be
very awkward to do for the page, since you can only add/remove object
stores and indexes from withing "versionchange" transactions. So it
seems unlikely that pages will do this a lot (though it will certainly
happen).

/ Jonas
Received on Monday, 26 March 2012 20:45:44 GMT

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