The IndexedDB Prototype Gets an Update

I'm happy to be able to give you an update today on the IndexedDB prototype, which we released late last year.

The version 1.0 prototype that we released in December was based on an editor's draft specification from November 2, 2010. I'm happy to announce that this new version includes some of the changes that were added to the specification since then, and which bring it in-line with the latest version of the spec that is available on the W3C web site. However, it is important to note that while this prototype is very close to the latest spec, it is not 100 percent compliant.

The protoype forms part of our HTML5 Labs Web site, a place where we prototype early and not yet fully stable drafts of specifications developed by the W3C and other standard organizations.  These prototypes will help us have informed discussions with developer communities, and give implementation experience with the draft specifications that will generate feedback to improve the eventual standards. It also lets us give the community some visibility on those specifications we consider interesting from a scenario point of view, but which are still not at the stage where we can consider them ready for official product support.

The goal of IndexedDB is to introduce a relatively low-level API that allows applications to store data locally and retrieve it efficiently, even if there is a large amount of it. The API is low-level to keep it really simple and to enable higher-level libraries to be built in JavaScript and follow whatever patterns Web developers think are useful as things change over time.

Folks from various browser vendors have been working together on this for a while now, and Microsoft has been working closely with the teams at Mozilla, Google and other W3C members that are involved in this to design the API together.

If you notice that this prototype of IndexedDB behaves differently and doesn't work with code you have written, it may be due to some of the following changes:

  • VERSION_CHANGE transaction as described in the spec is implemented except for one feature. The feature NOT implemented is the versionchange event to notify other open database connections, as in the specification. The workaround for this is to not launch two Internet Explorer tabs to open the same database.
  • The createObjectStore() method of the asynchronous database object is now a synchronous operation as described in the specification. Also, this method can only be called from within the onsuccess() handler of the IDBVersionChangeRequest object returned by the setVersion() method. See the samples in the CodeSnippets folder for the exact syntax.
  • The deleteObjectStore() method of the asynchronous database object can only be called from within the onsuccess() handler of the IDBVersionChangeRequest object returned by the setVersion() method. See the samples in CodeSnippets folder for examples.
  • The transaction method of the asynchronous database object now accepts parameters as described in the specification. See the sample in the CodeSnippets folder for examples.
  • The asynchronous transaction object now implements auto-commit. The Javascript code needs to have the close() method on the asynchronous database object for auto-commit to work. See the samples in the CodeSnippets folder for examples.

The goal of the prototypes is to enable early access to the API and get feedback from Web developers, as well as to keep it up to date with the latest changes in the specifications as they are published. But, since these are early days, remember that there is still time to change and adjust things as needed.

You can find out more about this experimental release and download the binaries from this archive, which contains the actual API implementation plus samples to get you started.

Claudio Caldato,

Principal Program Manager, Interoperability Strategy Team