IndexedDB APIs & Javascript.Next

Of the various specifications that are considered a part of HTML5, the IndexedDB API is one of the few APIs that are independent of the DOM and are impacted by Javascript. It would be an interesting to analyze the impact of newer Javascript features to this API set.
This post looks at current features of ECMA5 in addition to proposals in Harmony. I had previously posted slides for a talk on IndexedDB and the last slide touched briefly about this.

Modules
The module pattern has been widely accepted as a useful feature, thanks to CommonJS and specifically NodeJS implementations. Today, the IndexedDB object is a property of the global Window or WebWorker Objects. With modules, IndexedDB can be included into the code using something like require("IndexedDB") for async and require("IndexedDBSync") for the sync version of the API. With this distinction, will developers be allowed to use the sync version in non-web worker environments also?

Promises
Like modules, the promises pattern is also gaining traction. Currently, all Async operations on IndexedDB are on a IDBRequest Object. Should IDBRequest be changed to follow the Promises pattern?

Transaction Scope with Let and Var
With the changes in variable scopes using the let and var keywords, transaction scope will also be impacted. Transactions today auto-commit when the transaction variable goes out of scope and no more requests can be placed against it. With the Let statement, this could happen sooner inside blocks allowing even shorter transactions. This would also avoid closure related confusions in transaction scopes. This would also ensure that transactions variables are not leaked into the global scope.

Iterators
Iterating over a cursor today is done using a cursorRequest. Similar syntax should be used for iterating over cursors. The cursor.continue could be replaced with the iterator next method and the cursor could be treated as a collection. However, it would be interesting to see how the update and delete method on the cursor change for the new iterator pattern.

Generator Expressions and Array Comprehensions
While iterating over cursors, developers mostly perform some operations on the current item.Generator expressions are based on array comprehensions and make sense here, given the asynchronous nature of the API. Additionally, Array functions like each, filter, some, etc could also eliminate a lot of cursor boiler plate code. 

Destructuring Assignments
Continuing the discussion about cursors, the cursor.value and cursor.key return the key and the value respectively. However, restructuring assignments like [key, value] = cursor.continue() would help extract the keys and values easily. Similarly, doing something like [objectValue, key] = objectStore.get(id) could also be a useful notation.


Binary Blobs
With the introduction of Binary Blobs, specially for file, WebGL and devices API, it would be interesting to see how the databases (LevelDB or SQLite) store binary data and how they impact the quotas. I am guessing that indexing based on Binary Data would not be possible in the near future.


READ_WRITE/READ transaction modes and Object Freeze/Seal
Objects can be frozen or sealed to prevent them from being manipulated. In case of a READ transaction, the object obtained with a get or in cursors could be sealed and frozen to indicated that it was obtained from a READ transaction as opposed to a READ_WRITE transaction. This may however be an extreme way to indicate the transaction type.


Object Getters and Setters
With objects now having the ability define custom getters and setters, developers can use this method to provide a transparent abstraction that persists objects when properties are changed or loaded from a database when objects are read. Combining this with a Hibernate like query language could do ORM-magic that are traditionally done only with server-side languages. However, the logic on when to do (lazy vs eager) an async write or read would require some thought.

Classes
With the introduction of classes, it would be interesting to see schema for Object Stores. This may also change the way IndexedDB implementations could possibly change the way objects are stored internally. For example, IndexedDB on Firefox stored Blob for objects in SQLite today.

I have not come across similar documentation that discusses how IndexedDB works with new constructs in Javascript and I think this is an interesting topic of discussion. Please leave your opinions in the comments.