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.
Housekeeping data
IndexedDB is a non-relational database that saves Keys and Javascript objects. Certain meta data like Object Store Key Paths, index names, auto increment flags, database versions, etc. need to be store. Like WebSql using the sqlite_sequence to store autoincrement sequences, a database called __sysdb__ is used to save database versions. Additionally, every database created has a __sys__ table that stores the names of all stores with their meta-data (indexes, auto-increment flags, etc). This is very similar to the way Firefox IndexedDB Implementation persists meta data.
Keys and collation
The keys for data store can be of any Javascript type with rules specified for collation. WebSql however requires column types to be specified. To be able to save multi-type data, a blob column is used to keys and values. A key encoding scheme like the one by Firefox needs to be implemented to ensure collations.
Indexes
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.
Aborting Transactions
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
I noticed that the older specification and some libraries use event.target.result instead of request.result to get the return value of IDBRequest. Unfortunately, an Event object cannot have a custom target set on it. Hence, events for now are simply Javascript objects.
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.