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: 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 theIDBTransaction.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 orIDBFactory.deleteDatabase()
was requested elsewhere (most probably in another window/tab on the same computer). This is different from the version change transaction (seeIDBVersionChangeEvent
), 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
- Using IndexedDB
- Starting transactions:
IDBDatabase
- Using transactions:
IDBTransaction
- Setting a range of keys:
IDBKeyRange
- Retrieving and making changes to your data:
IDBObjectStore
- Using cursors:
IDBCursor
- Reference example: To-do Notifications (view example live.)