Warning:
This wiki has been archived and is now read-only.

IndexedDatabaseFeatures

From WEBAPPS
Jump to: navigation, search

This document is NO LONGER MAINTAINED. It was replaced by the Indexed Database Github Issues document.


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

New feature requests should be filed as issues at the spec repository:


https://github.com/w3c/IndexedDB/issues


All previous requests have been mirrored in the issue tracker.


Feature List

Easier Async Programming

  • ES6 Promises-based API (see #42)
  • IDBRequest.onerror for DataCloneError and DataError; Kyaw Tun on 20-May-2013 (see #42)
  • Transaction timeouts - jsbell (see #43)
    • 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 (see #44)
    • Or whatever primitives needed to support them.
    • May just need more powerful indexes plus text segmentation APIs
  • More powerful indexes (see #33)
    • For example, the ability to pass in index values during the objectStore.put/add call, or expressions/callbacks instead of plain keypaths.
  • Locale-aware sorting (Moz) (see #38)
    • Add 'locale' option to indexes (specified or 'platform')
    • Add 'IDBLocaleAwareKeyRange' when querying such an index (doesn't enforce upper/lower order if both specified)
    • Questions: are locales consistent across browsers? are collations stable?

Query Enhancements

  • request feedback on IDBKeyRange.inList() enhancement; Ben Kelly on 17-May-2013 (see #19)
  • Expand the concept of IDBKeyRange to allow boolean/set operations and index references. (see #45)
    • 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 (See #46)
  • Binary Keys; Joran Greef on 21-May-2012 (Bug 23332) Added to editor's draft: https://w3c.github.io/IndexedDB/
  • IDBKeyRange.forPrefix(string) - see Google Groups Post and p(r)ollyfill by Joshua Bell (see #47)

Storage Durability

This has been subsumed into an overall storage durability design: https://storage.spec.whatwg.org

Performance

  • IDBObjectStore require openKeyCursor method; Kyaw Tun 12-November-2012 - Added to editor's draft: https://w3c.github.io/IndexedDB/
  • IDBCursor should walk on secondary ordering of index value; Kyaw Tun 05-Dec-2012 (see #14),
    • e.g. IDBIndex.openCursor(index_key, direction, primary_key)
    • e.g. IDBCursor.continuePrimaryKey(index_key, primary_key)
  • IDBObjectStore/IDBIndex.exists(key) (see #48)
    • 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, ...]) - Added to editor's draft: https://w3c.github.io/IndexedDB/
  • Batched cursors (see #54)
    • Some implementations already "prefetch" several results to avoid DB/UI thread (or process) hops. Exposing this to script seems like a win.
    • 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.
  • One-shot transactions (see #34)
    • 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().
    • Alternately, allow the commit phase to be explicitly triggered, e.g. via a tx.commit() call.
  • Define flushing guarantees and expose control (see #50)
    • e.g. make transactions not flush-to-disk by default, but introduce a "readwriteflush" mode or {flush: true} option
  • Allow readwrite transactions restricted to a key range (see #59)
    • This would allow multiple transactions to operate on the same store
  • Grant access to other domains (see #60)
    • 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

Miscellaneous

  • URLs into IndexedDB databases by Jonas Sicking, 15-July-2013 (see #57)
  • Files on IndexedDB; piranna@gmail.com on 30-May-2013 (see #56)
  • Why not be multiEntry and array keyPath togather?; Kyaw Tun on 25-April-2013 (see #36)
  • Rewindable cursors (see #55)
  • Being able to cancel "versionchange" events (see #52)
    • 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. (see #31)
  • Return number of deleted records (see #32)
  • Allow renaming of Object Stores and Indexes during upgrade. - Added to Editor's Draft: https://w3c.github.io/IndexedDB/
  • Allow renaming/reversioning databases (see #53)
    • e.g. during a restore operation, may want to populate db: 'foo', version: 12, and swap it into place.
Retrieved from "https://www.w3.org/2008/webapps/wiki/index.php?title=IndexedDatabaseFeatures&oldid=2857"