Status: Initial thought experiment. Feedback welcome.
There are times when Indexed DB's transaction-centric API is too heavyweight:
- Reading a single value
- Writing a single value
- Using some other locking mechanism
- Writing, and want immediate commit (see also: Indexed DB: Fast Commit)
- Allow direct access to object stores and indexes (or rather, the script handles that represent them) off of the connection, and make simple (non-cursor, non-schema-mutation) methods available directly without going through a transaction.
- Return Promises rather than events, since the responses are simple.
var open = indexedDB.open('db');
// Schema definition process is unchanged by this proposal:
open.onupgradeneeded = function() {
var db = open.result;
var store = db.createObjectStore('store', {autoIncrement: true});
var index = store.createIndex('index', 'id');
store.put({id: 123});
store.put({id: 456});
store.put({foo: 'bar'});
};
// But now...
open.onsuccess = function() {
var db = open.result;
var store = db.objectStore('store');
store.get(1).then(r => console.log(r)); // {id: 123}
store.count().then(r => console.log(r)); // 3
var index = store.index('index');
index.count().then(r => console.log(r)); // 2
};
Issues:
- The naive idea is that 'read' operations are scheduled "as if" a
"readonly"
transaction were scheduled with the effective store in scope, and that 'write' operations are scheduled "as if" a"readwrite"
transaction were scheduled with the effective store in scope. While code targeting a single store would execute in the order written, code targeting multiple stores might not. - What about cursors?
- What about upgrade transactions? Does calling
db.objectStore('s').get()
return a promise (like normal), or a request (liketx.objectStore('s').get()
) or throw?