Please note, this is a STATIC archive of website developer.mozilla.org from November 2016, cach3.com does not collect or store any user information, there is no "phishing" involved.

Unsere Freiwilligen haben diesen Artikel noch nicht in Deutsch übersetzt. Machen Sie mit und helfen Sie, das zu erledigen!

The IDBDatabase interface of the IndexedDB API provides a connection to a database; you can use an IDBDatabase object to open a transaction on your database then create, manipulate, and delete objects (data) in that database. The interface provides the only way to get and manage versions of the database.

Note: This feature is available in Web Workers.

Note: Everything you do in IndexedDB always happens in the context of a transaction, representing interactions with data in the database. All objects in IndexedDB — including object stores, indexes, and cursors — are tied to a particular transaction. Thus, you cannot execute commands, access data, or open anything outside of a transaction.

Methods

Inherits from: EventTarget

IDBDatabase.close()
Returns immediately and closes the connection to a database in a separate thread.
IDBDatabase.createObjectStore()
Creates and returns a new object store or index.
IDBDatabase.deleteObjectStore()
Destroys the object store with the given name in the connected database, along with any indexes that reference it.
IDBDatabase.transaction()
Immediately returns a transaction object (IDBTransaction) containing the IDBTransaction.objectStore method, which you can use to access your object store. Runs in a separate thread.

Properties

IDBDatabase.name Read only
A DOMString that contains the name of the connected database.
IDBDatabase.version Read only
A 64-bit integer that contains the version of the connected database. When a database is first created, this attribute is an empty string.
IDBDatabase.objectStoreNames Read only
A DOMStringList that contains a list of the names of the object stores currently in the connected database.

Event handlers

IDBDatabase.onabort
Fires when access of the database is aborted.
IDBDatabase.onclose
Fires when the close event occurs; this happens when the database is unexpectedly closed, such as during application shutdown.
IDBDatabase.onerror
Fires when access to the database fails.
IDBDatabase.onversionchange

Fires when a database structure change (IDBOpenDBRequest.onupgradeneeded event or IDBFactory.deleteDatabase() was requested elsewhere (most probably in another window/tab on the same computer). This is different from the version change transaction (see IDBVersionChangeEvent), but it is related.

Example

In the following code snippet, we open a database asynchronously (IDBFactory), handle success and error cases, and create a new object store in the case that an upgrade is needed (IDBdatabase). For a complete working example, see our To-do Notifications app (view example live.)

// Let us open our database
  var DBOpenRequest = window.indexedDB.open("toDoList", 4);

  // these two event handlers act on the IDBDatabase object, when the database is opened successfully, or not
  DBOpenRequest.onerror = function(event) {
    note.innerHTML += '<li>Error loading database.</li>';
  };
 
  DBOpenRequest.onsuccess = function(event) {
    note.innerHTML += '<li>Database initialised.</li>';
    
    // store the result of opening the database in the db variable. This is used a lot later on
    db = DBOpenRequest.result;
    
    // Run the displayData() function to populate the task list with all the to-do list data already in the IDB
    displayData();
  };
 
  // This event handles the event whereby a new version of the database needs to be created
  // Either one has not been created before, or a new version number has been submitted via the
  // window.indexedDB.open line above
 
  DBOpenRequest.onupgradeneeded = function(event) {
    var db = event.target.result;
    
    db.onerror = function(event) {
      note.innerHTML += '<li>Error loading database.</li>';
    };

    // Create an objectStore for this database using IDBDatabase.createObjectStore
    
    var objectStore = db.createObjectStore("toDoList", { keyPath: "taskTitle" });
    
    // define what data items the objectStore will contain
    
    objectStore.createIndex("hours", "hours", { unique: false });
    objectStore.createIndex("minutes", "minutes", { unique: false });
    objectStore.createIndex("day", "day", { unique: false });
    objectStore.createIndex("month", "month", { unique: false });
    objectStore.createIndex("year", "year", { unique: false });

    objectStore.createIndex("notified", "notified", { unique: false });
    
    note.innerHTML += '<li>Object store created.</li>';
  };

This next line opens up a transaction on the Database, then opens an object store that we can then manipulate the data inside of.

    var objectStore = db.transaction('toDoList').objectStore('toDoList'); 

Specifications

Specification Status Comment
Indexed Database API
The definition of 'IDBDatabase' in that specification.
Recommendation Initial version
Indexed Database API (Second Edition)
The definition of 'IDBDatabase' in that specification.
Editor's Draft  

Browser compatibility

Feature Chrome Firefox (Gecko)[1] Internet Explorer Opera Safari (WebKit)
Basic support 23 webkit
24
10 moz
16 (16)
10, partial 15 7.1
Available in workers (Yes) 37 (37) ? (Yes) ?
close event ? 50 (50) ? ? ?
Feature Android Firefox Mobile (Gecko) Firefox OS IE Phone Opera Mobile Safari Mobile
Basic support 4.4 22.0 (22) 1.0.1 10 22 8
Available in workers (Yes) 37.0 (37) (Yes) ? (Yes) ?
close event ? 50.0 (50) ? ? ? ?

[1] As of Firefox 40, IndexedDB transactions have relaxed durability guarantees to increase performance (see bug 1112702). Previously in a readwrite transaction IDBTransaction.oncomplete was fired only when all data was guaranteed to have been flushed to disk. In Firefox 40+ the complete event is fired after the OS has been told to write the data but potentially before that data has actually been flushed to disk. The complete event may thus be delivered quicker than before, however, there exists a small chance that the entire transaction will be lost if the OS crashes or there is a loss of system power before the data is flushed to disk. Since such catastrophic events are rare most consumers should not need to concern themselves further. If you must ensure durability for some reason (e.g. you're storing critical data that cannot be recomputed later) you can force a transaction to flush to disk before delivering the complete event by creating a transaction using the experimental (non-standard) readwriteflush mode (see IDBDatabase.transaction).

See also

 

Schlagwörter des Dokuments und Mitwirkende

 Zuletzt aktualisiert von: Sheppy,