Friday, May 11, 2012

IndexedDB setVersion vs onupgradeneeded

Try out the latest version of the plugin -

The latest specification of IndexedDB has removed the setVersion method and uses the newupgradeneeded method instead. In an older post, I had written about this change to the jquery-indexeddb plugin. However, Chrome still does not support the onupgradeneeded method and hence, the new version of jquery indexeddb plugin had to have a different name.
Over the past few weeks, I was able to work on some code that would wrap the method to allow the onupgradeneeded method. Instead of deeply coupling the setVersion-onupgradeneeded shim with the jquery plugin, I was able to get it to work as an independent shim that could also be used with standard IndexedDB applications.

Using the shim
To use the shim, simply include this javascript, and instead of calling, call openReqShim. The events fired would be onsuccess, onerror, onblocked, and onupgradeneeded, as in the specification. The onupgradeneeded would have a versionTransaction that can be used to create/delete objectStores or Indexes.

Inside the shim

A database is opened when the openReqShim() call is made, very similar to call. The database name, and an optional database version are passed to this call, similar to the original call. The call returns the IDBRequest object.

For Firefox
In case of firefox, when the database is opened with the specified version greater than the database version, the onupgradeneeded method is called. This call is passed to the callback specified by the user. This is followed by a call to onsuccess, that is also passed to the user's onsuccess function.

For Chrome
In case of chrome, the onupgradeneeded function is not called. The database's onsuccess function is called. Here, the existence of the setVersion method is checked. If the method exists, and the specified version is greater than the database version, a the setVersion method is called. The onsuccess of the setVersion's request call invokes the user's onupgradeneeded method with the version transaction. Once the method completes, the versionTrasnaction is committed by closing the database. The database is opened again with the latest version and this is passed to the onsuccess defined by the user.

The above shim tries to make the programming interface for the IndexedDB API confirm to the specification for Chrome. The latest version of the specification has also deprecated constants like IDBTransaction.READ_WRITE, replacing them with string constants like "readwrite". This change is currently available in Firefox Aurora and Chrome Canary, and I am working on it now, so you can watch out this space for any updates.


Daniel Gerson said...

Am dying to use your framework... but Chrome canary isn't good enough. I need it working in Chrome :-(

Daniel Gerson said...

I just installed Chrome Canary, and I get failures running your tests in both the stable version and canary. Failing tests like the add/get object... which I image is pretty fundamental no? What am I to make of this?

axemclion said...

 It does work on Chrome - What version are you seeing the tests failing in ?

Devques said...

Firefox 12 broke IndexedDB that worked in Firefox 11, and now
Firefox 13 breaks the IndexedDB revisions that worked in Firefox 12, what a nightmare.
[Exception... "A mutation operation was attempted on a database that did not allow mutations." code: "6" nsresult: "0x80660006 (NS_ERROR_DOM_INDEXEDDB_NOT_ALLOWED_ERR)"

Parashuram said...

The way the tests are written is not the best way to write unit tests. Are they failing always ?

Parashuram said...

Which line number is that ?

Parashuram said...

Just fixed these - can you try again please ?

Owen said...

I am using chrome v 22.0.1229.94 m.

Tried to run your code to change the version number.

the blocked function for version change request gets called all the time. (which is expected from your code), but the code never lands in the onsuccess for version change...

Post a Comment