Tuesday, June 12, 2012
IndexedDB Polyfill - Under the covers
I have been working on an IndexedDB polyfill that enables the API for browsers like Opera and Safari that still do not support it. The polyfill enables the IndexedDB API to be available on browsers that support WebSql including devices like iPad and iPhone. This post is about the interesting issues that I encountered while developing the plugin. For more context, you should check out the IndexedDB Specification, WebSQL Specification and the polyfill source code.
Keys and collation
Indexes are created by simply creating a new column in the same table, extracting the index-key-path from the value and then and indexing that column. This is different from the way Firefox or Chrome implement indexes by using a different table, but this was a lot easier to write. I am still trying to find the reason why indexes were implemented as separate tables (multi value indices ? )
Synchronous Create Operations
The IndexedDB specification indicates that createObjectStore and createIndex operations are synchronous. However, WebSql does not allow synchronous operations. To overcome this limitation, all object stores have an internal __ready flag that is set to false for createObjectStore or createIndex when object stores or indexes are created. Operations are added to the transaction queue once these are reset. This has to be replaced with a mechanism that ensures that operations are only queued during a version transaction. Note that this needs to be persisted such that the flag is available across tabs - possibly saving this in the database, or simply using a cookie.
WebSQL does not provide a direct way to abort transaction. To mock an abort operation, an exception is thrown when inside the transaction.
Events and event.target
Note that some of the points discussed above are still marked as open issues - any help would be welcome!
You can watch out this space for more updates.