IndexedDatabaseFeatures

From WEBAPPS
Jump to: navigation, search

This wiki documents requests for Indexed Database features that are not included in the first edition 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 public-webapps@w3.org list (please use with a Subject header of "[IDB Feature Request]").

Feature List

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

Easier Async Programming

  • ES6 Promises-based API
  • IDBRequest.onerror for DataCloneError and DataError; Kyaw Tun on 20-May-2013
  • 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

Index Enhancements

  • 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)

Query Enhancements

  • request feedback on IDBKeyRange.inList() enhancement; Ben Kelly on 17-May-2013 (see Bug 16595)
  • 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(IDBQuery.is("name", "alice"), IDBQuery.is("salary", IDBKeyRange.bounds(1e5,2e5))))
    • This could be the target of an ES6 "tagged template string" microsyntax compiler.
  • Regular Expression search; Michael Brooks on 31-July-2012
  • Binary Keys; Joran Greef on 21-May-2012 (Bug 23332)
  • IDBKeyRange.forPrefix(string) - see Google Groups Post and p(r)ollyfill by Joshua Bell

Storage Durability

Performance

  • IDBObjectStore require openKeyCursor method; Kyaw Tun 12-November-2012
  • 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/IDBIndex.exists(key)
    • For stores this is the same as count(key), but would be cheaper for indexes.
  • 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.
  • 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.
  • Explicitly allow reorderable transactions: bug 25251
    • See email thread
    • That is: add a new type of readonly tx that can run even if a readwrite tx would otherwise be blocking it, operating on a snapshot.
  • One-shot transactions
    • For write-only transactions, all of the requests can be made in the creation scope, and there's no need to wait for all of the request success events to propagate back to script before attempting to commit. This could be done by adding an {immediateCommit:true} flag to db.transaction().
  • Allow readwrite transactions restricted to a key range
    • This would allow multiple transactions to operate on the same store
  • Grant access to other domains
    • Currently this requires opening an iframe and proxying all data access (hence, perf issue)
    • One approach would be to make IDBDatabase connection objects Transferable; then they could be passed between cooperating frames via postMessage()

Error Reporting

Observers

Spec Refinement

  • Define order for operations that raise multiple exceptions types (see Bug 17681)
  • Remove DOMStringList usage (see Bug 16103)
  • Remove DOMError from IDB (see Bug 27727
  • IDB exposes GC behavior (see Bug 25223

Miscellaneous

  • URLs into IndexedDB databases by Jonas Sicking, 15-July-2013
  • Files on IndexedDB; piranna@gmail.com on 30-May-2013
  • Why not be multiEntry and array keyPath togather?; Kyaw Tun on 25-April-2013 (see Bug 21836)
  • Rewindable cursors
  • 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.
  • Database enumeration e.g. IDBFactory.databases, but non-racy, with guarantees that the set of databases doesn't change. (Bug 16137)
  • Return number of deleted records (see Bug 22130)
  • Allow renaming of Object Stores and Indexes during upgrade.
Retrieved from "http://www.w3.org/2008/webapps/wiki/index.php?title=IndexedDatabaseFeatures&oldid=2717"