Jump to: navigation, search

This wiki documents requests for Indexed Database features that are not included in the first version of the spec.

Those with write access to this document are encouraged to update this document and/or to use Bugzilla to submit a feature request. Also, see:

If you cannot create a Bugzilla bug for a change requests and/or feature, send your request to the WG's list (please use with a Subject header of "[IDB Feature Request]").

Feature List

Indexed Database feature requests that are not included in the first version of the spec:

  • Syntax for specifying persistent/temporary storage; Jan Varga on 06-Dec-2013
  • URLs into IndexedDB databases by Jonas Sicking, 15-July-2013
  • Files on IndexedDB; on 30-May-2013
  • IDBRequest.onerror for DataCloneError and DataError; Kyaw Tun on 20-May-2013
  • Inform script of corruption recovery; Kyaw Tun on 20-May-2013. Original comment was submitted by David Grogan on 11-Feb-2013 (see Bug 22370)
  • Why not be multiEntry and array keyPath togather?; Kyaw Tun on 25-April-2013 (see Bug 21836)
  • request feedback on IDBKeyRange.inList() enhancement; Ben Kelly on 17-May-2013
  • IDBCursor should walk on secondary ordering of index value; Kyaw Tun 05-Dec-2012 (see Bug 20257)
    • e.g. IDBObjectStore.openCursor(index_key, direction, primary_key)
    • e.g. IDBCursor.continuePrimaryKey(index_key, primary_key)
  • IDBObjectStore require openKeyCursor method; Kyaw Tun 12-November-2012
  • Regular Expression search; Michael Brooks on 31-July-2012
  • Binary Keys; Joran Greef on 21-May-2012 (Bug 23332)
  • ObjectStores should have a way to hint that they're "evictable"; Jeremy Orlow; see Bug 11350
  • Being able to cancel "versionchange" events
    • This would allow a page to signal back to the page calling setVersion that a version upgrade isn't possible right now. Not sure if there are terribly good use cases though.
  • Fast cursors
    • The implementation can load several entries at once, expecting that .continue() will be called. However, since we have a requirement that callbacks always happen in the order they were placed, if calls to .continue() is intermixed with other requests, the "prefetching" of cursor content is basically destroyed. We can fix this by allowing "fast" cursor iteration. Callbacks for such iteration would be prioritized and fire before all other callbacks. We can do this either through a objectStore.openFastCursor() API, or a cursot.fastContinue() API.
    • Or, explicitly specify how many records to fetch (on cursor open or continue) and deliver key/primaryKey/value as arrays. This saves the overhead of returning to the event loop for each new value.
  • Database Observers
  • Fulltext index
    • Or whatever primitives needed to support them.
    • May just need more powerful indexes plus text segmentation APIs
  • More powerful indexes
    • For example the ability to pass in index values during the objectStore.put/add call, or expressions/callbacks instead of plain keypaths. (Bug 10000)
  • IDBObjectStore/IDBIndex.exists(key)
    • For stores this is the same as count(key), but would be cheaper for indexes.
  • Database enumeration e.g. IDBFactory.databases, but non-racy, with guarantees that the set of databases doesn't change. (Bug 16137)
  • Rewindable cursors
  • Remove DOMStringList usage (see Bug 16103)
  • Define order for operations that raise multiple exceptions types (see Bug 17681)
  • Fire event when database connection is forcibly closed (see Bug 22540)
  • IDBKeyRange.forPrefix(string) - see Google Groups Post and p(r)ollyfill by Joshua Bell
  • ES6 Promises-based API
  • Batched gets
    • e.g. store.getAll(range), or store.getAll([key, ...])
    • Need to consider the API and ensure it really is a win; early Moz experiments showed that just firing off many parallel get() requests was almost the same speed; that's predicated on being able to identify all the keys at query time, though.
    • Relevant thread on performance experiments [1]
  • Batched cursors
    • Some implementations already "prefetch" several results to avoid DB/UI thread (or process) hops. Exposing this to script seems like a win.
  • Expand the concept of IDBKeyRange to allow boolean/set operations and index references.
    • This would be the primitives necessary for a query language that could be executed on the DB thread/process
    • Needs a real proposal, but the general idea is something like this assuming "name" and "salary" indexes on store:
      • store.get(IDBQuery.and("name", "alice"),"salary", IDBKeyRange.bounds(1e5,2e5))))
    • This could be the target of an ES6 "tagged template string" microsyntax compiler.
  • Explicitly allow reorderable transactions: bug 25251
  • If errors are not prevented, call window.onerror
    • Already implemented in Firefox
    • Chrome implementation in progress
  • Transaction timeouts - jsbell
    • Already implemented in Chromium to deal with unresponsive renderers (though the timer restarts on any new activity)
    • May be necessary to work with Promises, e.g. tx.waitUntil(p), if p never resolves/rejects