scaljeri / indexeddb-vs-websql Goto Github PK

for (var i = 0; i < db.objectStoreNames.length; i ++) {
  console.info('delete object store: ' + db.objectStoreNames[i]) ;
  db.deleteObjectStore(db.objectStoreNames[i]);
}

This will fail for multiple stores, as length will decrease as the stores are deleted while the counter will be incremented. You probably want:

while (db.objectStoreNames.length)
  db.deleteObjectStore(db.objectStoreNames[0]);

And the test overall will only test prefixed versions of the API:

idb = getIndexedDBObject( 'IndexedDB' ) ;

function getIndexedDBObject(name) {
  return window[name] || window['webkit' + name] || window['moz' + name] || window['ms' + name] ;
}

That will attempt to use window.IndexedDB but the standard API entry point is window.indexedDB so this always falls back to a prefixed version, and will break if they are removed.

Hi there, some possible extra things to consider:

• For read-single and read-multi, readTransaction should be used instead of regular rw transaction. This might give some small benefit.
• read-multi currently executes a query that returns multiple rows. Another notion of read-multi would be making several SELECT in a single transaction, or multiple transactions each with a single SELECT. From my experience multiple transactions each with a single-select is about an order of magnitude slower than a single transaction with multiple selects, possibly due to SQLite needing to acquire/release a shared lock each time coupled with whatever internal transaction-level bookkeeping websql does. Would be interesting to see how indexeddb compares for this usage pattern.