indexedDB Updates – FF4.09b

IndexedDB is all the buzz right now, but it is pretty hard to find information about it’s implementations. In addition to that, the impls change on a weekly basis. So I figured it would be nice to summarize every now and then what has been happening around IDB in the last time.

And as Mozilla released a new Firefox 4 beta these days, and introduces changes to it’s IDB impl, let’s start the series with a brief summary of the most important of these changes.

Changes in 4.09b

The indexedDB object has been renamed: moz_indexedDB is now mozIndexedDB.
When opening a database, the event handed over to the onsuccess callback no more has a property called “result”, where a reference to the databasse used to be; it is now available at event.target.result (event.target contains the IDBRequest).
This applies to many (all?) cases, where you’d expect the result of a request to live in event.result, where it now is in event.target.result.
When creating an object store, the second argument, keyPath, now has to be passed as a property inside of an object: {keyPath: "keyPathName"}
When creating an objectStore, the third argument, autoIncrement, is dropped and now has to be part of the second argument: {autoIncrement: true}
Methods that read from an objectStore now only seem to work inside of a transaction; before, it was allowed to call methods like get directly.
keyRange support seems to have increased. However, I’m not really interested (right now) in keyRanges and queries, so I did not play around with these.

Note that the changes for the createObjectStore arguments are against the spec – the 4.08b was compliant, the 4.09b is no more. But, on the other hand, it is now closer to the Chrome impl, which also expects an object as second argument (but has no support for autoIncrement).

What it does not have (yet)

The sync API. Alas. To me, the snychronous implementation is exactly what makes indexedDB that attractive – I’m not a fan of databases and I don’t like to start transactions, iterate over resultSets and the like… I want a store with easy access. Seriously, in most real life scenarios, an async approach won’t get you anywhere but displaying a waiting message to your user, because you can’t go on until you have the data from the store.

More info?

If you want to stay in touch with what happens around the indexedDB impl, the best place to go ist the Mozilla bugtracker. Um, yeah, reading browser source code can be no fun at times, but it gets you as close as you can get. Or, check what happens in the test files.

Need working code?

The *only* place to get reliable, working code is the test files in the repository. Seriously, there’s so much code out there claiming to work, but it simply doesn’t. And even if it did one day, it might break the other day, after changes have been made to the impl. And there will be *lots* of changes in the future.

Where are these test files?

In the repo. To see them online, go here: http://hg.mozilla.org/mozilla-central/file/ and then navigate to dom/indexedDB/test.

Something else?

Nope, not really. There don’t seem to be any *major* changes for 4.09b – I hope you still found this short summary useful.

I hope to continue this series about IDB and post about different IDB topics every now and then – so if you want to know more about indexedDB in general, or something specific, just drop a line in the comments!