Copyright © 2011 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document defines APIs for a database of records holding simple values and hierarchical objects. Each record consists of a key and some value. Moreover, the database maintains indexes over records it stores. An application developer directly uses an API to locate records either by their key or by using an index. A query language can be layered on this API. An indexed database can be implemented using a persistent B-tree data structure.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document was published by the Web Applications Working Group as a Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-webapps@w3.org (subscribe, archives). All feedback is welcome.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This section is non-normative.
User agents need to store large numbers of objects locally in order to satisfy off-line data requirements of Web applications. [WEBSTORAGE] is useful for storing pairs of keys and their corresponding values. However, it does not provide in-order retrieval of keys, efficient searching over values, or storage of duplicate values for a key.
This specification provides a concrete API to perform advanced key-value data management that is at the heart of most sophisticated query processors. It does so by using transactional databases to store keys and their corresponding values (one or more per key), and providing a means of traversing keys in a deterministic order. This is often implemented through the use of persistent B-tree data structures that are considered efficient for insertion and deletion as well as in-order traversal of very large numbers of data records.
TODO: Add examples using the sync and the async APIs.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [RFC2119].
This specification defines one class of products:
A user agent must behave as described in this specification in order to be considered conformant.
User agents may implement algorithms given in this specification in any way desired, so long as the end result is indistinguishable from the result that would be obtained by the specification's algorithms.
A conforming Indexed Database API user agent must also be a conforming implementation of the IDL fragments of this specification, as described in the “Web IDL” specification. [WEBIDL]
This specification relies on several other underlying specifications.
Function,
origin, same origin, structured clone,
structured clone algorithm, task, task source,
and queue a task are defined by the HTML 5
specification [HTML5].
Worker is defined by
the WebWorkers specification [WEBWORKERS].Each origin has an associated set of databases. A database comprises one or more object stores which hold the data stored in the database.
Every database has a name which identifies it within a specific origin. The name can be any string value, including the empty string, and stays constant for the lifetime of the database. Each database also has a current version. When a database is first created, its version is the empty string.
Implementations must support all names. If a implementation uses a storage mechanism which can't handle arbitrary database names, the implementation must use an escaping mechanism or something similar to map the provided name to a name that it can handle.
Each database has one version at a time; a database can't exist in multiple versions at once. The only way to change the version is using a VERSION_CHANGE transaction.
Databases has a delete pending flag which is used during deletion. When a database is requested to be deleted the flag is set to true and all attempts at opening the database are stalled until the database can be deleted.
The act of opening a database creates a connection. There may be multiple connections to a given database at any given time. Each connection has a closePending flag which initially is set to false.
When a connection is initially created it is in opened state. The connection can be closed through several means. If the connection is GCed or execution context where the connection is created is destroyed (for example due to the user navigating away from that page), the connection is closed. The connection can also be closed explicitly using the steps for closing a database connection. When the connection is closed the closePending flag is always set to true if it hasn't already been.
The IDBDatabase and IDBDatabaseSync
interfaces represent a connection to a database.
An object store is the primary storage mechanism for storing data in a database.
Each database contain a set of object stores. The set of object stores can be changed, but can only be changed using a VERSION_CHANGE transactions. When a new database is created it doesn't contain any object stores and has the empty string as version.
The object store has a list of records which hold the data stored in the object store. Each record consists of a key and a value. The list is sorted according to key in ascending order. There can never be multiple records in a given object store with the same key.
Every object store has a name. The name is unique within the database to which it belongs. Every object store also optionally has a key generator and an optional key path. If the object store has a key path it is said to use in-line keys. Otherwise it is said to use out-of-line keys.
The object store can derive the key from one of three sources. Which source is used is determined when the object store is created. The three sources are:
specify that generators are not shared between stores.
The IDBObjectStore and IDBObjectStoreSync
interfaces represent a object store. Note however that multiple instances of those
interfaces representing the same object store can exist.
In order to efficiently retrieve records stored in an indexed database,
each record is organized according to its key. A value is said to be a valid key
if it is one of the following types:
Array JavaScript objects [ECMA-262],
DOMString [WEBIDL],
Date [ECMA-262] or float [WEBIDL].
However Arrays are only valid keys if every item in the array is defined and is
a valid key (i.e. sparse arrays can not be valid keys).
Any non-numeric properties are ignored, and thus does not affect if the Array is a valid key.
Additionally, if the value is of type float, it is only a valid key if it is not NaN.
Conforming user agents must support all valid keys as keys.
Infinite float values are valid keys. As are empty Arrays.
For purposes of comparison, all Arrays are greater than all DOMString,
Date and float values; all DOMString values are greater than all
Date and float values; and all Date values are greater than all
float values. Values of type float are compared to other float values
numerically. Values of type Date are compared to other Date values chronologically.
Values of type DOMString are compared to other values of type DOMString according
to the collation of the object store or index where the value is used as a key. Values
of type Array are compared to other values of type Array as follows:
Array value and B be the second Array
value.
Note that Arrays that contain other Arrays are allowed as valid keys.
In this case the algorithm above runs recursively when comparing the individual values in the arrays.
As a result of the above rules, an empty Array is the lowest possible key, while positive
infinity is the highest possible key.
The terms greater than, less than and equal to is defined in the terms of the above comparisons.
Each record is associated with a value. Conforming user agents must support
any value supported by the structured clone algorithm
[HTML5]. This includes simple types such as DOMString
and Date as well as Object and Array
instances.
A key path is a DOMString that defines how to extract a key from a value.
A valid key path is
either the empty string, a JavaScript identifier, or multiple Javascript identifiers separated by
periods (ASCII character code 46) [ECMA-262]. (Note that spaces are not allowed
within a key path.) To evaluate a key path, run the
steps for extracting a key from a value using a key path.
It is sometimes useful to retrieve records in a object store through other means than their key. A index allows looking up records in a object store using properties of the values in the object stores records.
An index is a specialized persistent key-value storage and has a referenced object store. The index has a list of records which hold the data stored in the index. The records in an index are automatically populated whenever records in the referenced object store are inserted, updated or deleted. There can be several indexes referencing the same object store, in which changes to the object store cause all such indexes to get updated.
The values in the index's records are always values of keys in the index's referenced object store. The keys are derived from the referenced object store's values using a key path. If a given record with key X in the object store referenced by the index has the value A, and evaluating the index's key path on A yields the result Y, then the index will contain a record with key Y and value X.
Records in an index are said to have a referenced value. This is the value of the record in the index's referenced object store which has a key equal to the index's record's value. So in the example above, the record in the index whose key is Y and value is X has a referenced value of A.
Each record in an index reference one and only one record in the index's referenced object store. However there can be multiple records in an index which reference the same record in the object store. And there can also be no records in an index which reference a given record in an object store.
The records in an index are always sorted according to the records key. However unlike object stores, a given index can contain multiple records with the same key. Such records are additionally sorted according to the records value.
An index contains a unique flag. When this flag is set to true, the index enforces that no two records in the index has the same key. If a record in the index's referenced object store is attempted to be inserted or modified such that evaluating the index's key path on the records new value yields a result which already exists in the index, then the attempted modification to the object store fails.
An index also contains a multirow flag. This flag affects how the index behaves when the result of evaluating
the index's key path yields an Array. If the multirow flag is false, then
a single record whose key is an Array is added to the index. If the multirow flag is
true, then the one record is added to the index for each item in the Array. The key for each
record is the value of respective item in the Array.
The IDBIndex and IDBIndexSync interfaces
provide access to the metadata of an index. Note however that multiple instances of those
interfaces representing the same index can exist.
A transaction is used to interact with the data in a database. Whenever data is read or written to the database this is done using a transaction.
All transactions are created using a connection, which is the transactions connection. The transaction has a mode which determines which types of interactions can be performed using the transaction. The mode is set when the transaction is created and remains constant for the lifetime of the transaction. The transaction also has a scope which determines which object stores the transaction can interact with. Finally, transactions have a active flag, which determines if new requests can currently be placed against the transaction. Finally, transactions also contain a request list of requests which have been placed against the transaction.
Transactions have a constant scope which is determined when the transaction is created and remains constant for the lifetime of the transaction.
Transactions offer some protection from application and system failures. A transaction may be used to store multiple data records or to conditionally modify certain data records. A transaction represents an atomic and durable set of data access and mutation operations.
Transactions are expected to be short lived. This is encouraged using the automatically committing functionality described below. Authors can still cause transactions to run for a long time, however this is generally not a usage pattern which is recommended and can lead to bad user experience in some implementations.
The lifetime of a transaction is as follows:
A transaction can be aborted at any time before it is finished. Including if it isn't active or hasn't yet started.
Transactions are opened in one of three modes. The mode determine how concurrent access to object stores in the transaction is isolated.
READ_ONLYREAD_WRITEVERSION_CHANGE
The transaction mode determines both which operations are allowed to be performed
during the transaction, as well whether two transactions can run concurrently or not.
Which operations are allowed be be performed are defined in detail below, but in general
transactions opened in READ_ONLY mode are only allowed to perform
reading operations which does not change data. READ_WRITE transactions are allowed to
perform reading and writing transactions to existing object stores, where as
VERSION_CHANGE transactions are allowed to perform any operations, including ones that
delete and create object stores and indexes.
A VERSION_CHANGE transaction can never run concurrently with other transactions. When a VERSION_CHANGE transaction is created, the implementation must wait to start the VERSION_CHANGE transaction until no other transactions against the same database are running. As long as the VERSION_CHANGE transaction, the implementation must wait with starting any other transactions against the same database until the VERSION_CHANGE transaction is finished.
Any number of transactions opened in READ_ONLY mode are allowed to run concurrently, even if the transaction's scope overlap and include the same object stores. As long as a READ_ONLY transaction is running, the data that the implementation returns through requests created with that transaction must remain constant. That is, two requests to read the same piece of data must yield the same result both for the case when data is found and the result is that data, and for the case when data is not found and a lack of data is indicated.
There are a number of ways that an implementation ensure this. It can prevent READ_WRITE transactions whose scope overlap the scope of the READ_ONLY transaction from starting until the READ_ONLY transaction is finished. Or it can allow the READ_ONLY transaction to see a snapshot of the contents of the object stores which is taken when the READ_ONLY transaction is started.
Similarly, implementations must ensure that a READ_WRITE transaction is only affected by changes to object stores that are made using the transaction itself. I.e. the implementation must ensure that another transaction does not modify the contents of object stores in the READ_WRITE transactions scope. The implementation must also ensure that if the READ_WRITE transaction completes successfully, that the changes written to object stores using the transaction can be committed to the database without merge conflicts. An implementation must not abort a transaction due to merge conflicts.
An implementation must not start any transaction until all other READ_WRITE transactions with overlapping scope have completed. When multiple transactions are eligible to be started, older transactions should be started first.
User agents must ensure a reasonable level of fairness across transactions to prevent starvation. For example if multiple READ_ONLY transaction are started one after another the implementation must ensure that that doesn't indefinitely prevent a pending READ_WRITE transaction from starting.
Conforming user agents must automatically abort a transaction at the end of the scope in which it was created, if an exception is propagated to that scope.
Transaction objects implement the
IDBTransaction or the
IDBTransactionSync interfaces.
Each reading and writing operation on a database is done using a request. Every request represents one read or write operation. Requests have a done flag which initially is false, and a source object. Every request also has a result and an errorCode, neither of which are accessible until the done flag is set to true.
Finally, requests have a request transaction. When a request is created, it is always placed against a transaction using either the steps to a asynchronously execute a request or the steps to a synchronously execute a request. This sets the request transaction to be that request. The only exceptions to this are the request returned from a IDBFactory.open call and the request returned from a IDBDatabase.setVersion call, which create requests which have a null request transaction.
Records can be retrieved from object stores and indexes using either keys or key ranges. A key range is a continuous interval over some data type used for keys.
A key range may be lower-bounded or upper-bounded if there is a value that is, respectively, smaller than or larger than all its elements. A key range is said to be bounded if it is both lower- and upper-bounded and unbounded otherwise. A key range may be open, i.e., not including its endpoints or closed, i.e., including its endpoints. A key range may consist of a single value.
The IDBKeyRange interface defines a
key range.
interface IDBKeyRange {
readonly attribute any lower;
readonly attribute any upper;
readonly attribute boolean lowerOpen;
readonly attribute boolean upperOpen;
static IDBKeyRange only (in any value) raises (IDBDatabaseException);
static IDBKeyRange lowerBound (in any bound, in optional boolean open) raises (IDBDatabaseException);
static IDBKeyRange upperBound (in any bound, in optional boolean open) raises (IDBDatabaseException);
static IDBKeyRange bound (in any lower, in any upper, in optional boolean lowerOpen, in optional boolean upperOpen) raises (IDBDatabaseException);
};
lower of type any, readonlylowerOpen of type boolean, readonlyupper of type any, readonlyupperOpen of type boolean, readonlybound| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| lower | any |
✘ | ✘ | The lower-bound value |
| upper | any |
✘ | ✘ | The upper-bound value |
| lowerOpen | boolean |
✘ | ✔ | Is the lower-bound value included in the key range. Defaults to false. |
| upperOpen | boolean |
✘ | ✔ | Is the upper-bound value included in the key range. Defaults to false. |
| Exception | Description | ||
|---|---|---|---|
IDBDatabaseException |
|
static IDBKeyRangelowerBoundundefined and
and upperOpen set to true.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| bound | any |
✘ | ✘ | The lower bound value |
| open | boolean |
✘ | ✔ | Is the lower-bound value included in the key range. Defaults to false. |
| Exception | Description | ||
|---|---|---|---|
IDBDatabaseException |
|
static IDBKeyRangeonly| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| value | any |
✘ | ✘ | The only value |
| Exception | Description | ||
|---|---|---|---|
IDBDatabaseException |
|
static IDBKeyRangeupperBoundundefined, lowerOpen set to true,
upper set to value and
and upperOpen set to open.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| bound | any |
✘ | ✘ | The upper bound value |
| open | boolean |
✘ | ✔ | Is the upper-bound value included in the key range. Defaults to false. |
| Exception | Description | ||
|---|---|---|---|
IDBDatabaseException |
|
static IDBKeyRangeA key is in a key range if both the following conditions are fulfilled:
Cursors are a transient mechanism used to iterate over multiple records in a database. The storage operations are performed on the underlying index or an object store.
A cursor comprises a range of records in either an index or an object store. The cursor has a source indicating which index or object store whose records it is iterating. A cursor maintains a position over this series, which moves in a direction that is either monotonically increasing or decreasing order of the record keys. Cursors also have a key and a value which represent the key and the value of the last iterated record. Cursors finally have a got value flag. When this flag is false, the cursor is either in the process of loading the next value or it has reached the end of its range, when it is true, it indicates that the cursor is currently holding a value and that it is ready to iterate to the next one.
If the source of a cursor is a object store, the effective object store of the cursor is that object store and the effective key of the cursor is the cursors position. If the source of a cursor is a index, the effective object store of the cursor is that index's referenced object store and the effective key is the cursors object store position.
It is possible for the list of records which the cursor is iterating over to change before the full range of the cursor has been iterated. In order to handle this, cursors maintain their position not as an index, but rather as a key of the previously returned record. For a forward iterating cursor, the next time the cursor is asked to iterate to the next record it returns the record with the lowest key greater than the one previously returned. For a backwards iterating cursor, the situation is opposite and it returns the record with the highest key less than the one previously returned.
For cursors iterating indexes the situation is a little bit more complicated since multiple records can have the same key and are therefor also sorted by value. When iterating indexes the cursor's also has a object store position, which indicates the value of the previously found record in the index. Both position and the object store position is used when finding the next appropriate record.
Cursor objects implement the IDBCursor
or the IDBCursorSync interfaces. There is only ever one
IDBCursor or IDBCursorSync instance representing
a given cursor. However there is no limit on how many cursors can be used at the
same time.
IDBDatabaseException Interfaceexception IDBDatabaseException {
const unsigned short UNKNOWN_ERR = 1;
const unsigned short NON_TRANSIENT_ERR = 2;
const unsigned short NOT_FOUND_ERR = 3;
const unsigned short CONSTRAINT_ERR = 4;
const unsigned short DATA_ERR = 5;
const unsigned short NOT_ALLOWED_ERR = 6;
const unsigned short TRANSACTION_INACTIVE_ERR = 7;
const unsigned short ABORT_ERR = 8;
const unsigned short READ_ONLY_ERR = 9;
const unsigned short TIMEOUT_ERR = 10;
const unsigned short QUOTA_ERR = 11;;
attribute unsigned short code;
attribute DOMString message;
};
code of type attribute unsigned shortmessage of type attribute DOMStringABORT_ERR of type unsigned shortIDBTransaction.abort.CONSTRAINT_ERR of type unsigned shortDATA_ERR of type unsigned shortNON_TRANSIENT_ERR of type unsigned shortNOT_ALLOWED_ERR of type unsigned shortNOT_FOUND_ERR of type unsigned shortQUOTA_ERR of type unsigned shortREAD_ONLY_ERR of type unsigned shortTIMEOUT_ERR of type unsigned shortTRANSACTION_INACTIVE_ERR of type unsigned shortUNKNOWN_ERR of type unsigned shortThese codes are in flux and may change entirely as exception/error handling may be changing in the WebIDL spec.
Options objects are simply JavaScript objects [ECMA-262]
which are used to supply optional parameters to some indexedDB functions like
createObjectStore and
createIndex. The attributes on the object
correspond to optional parameters on the function called. The domain of valid
attributes/parameters depends on the function called. If an attribute is present in the
object which is not part of that domain, a
NON_TRANSIENT_ERR exception
must be thrown. Similarly, if any attribute has a getter function or its value is an object, a
NOT_TRANSIENT_ERR exception must be thrown.
We disallow getters and objects because the getter function and the toString function can execute arbitrary JavaScript which exposes many obscure corner cases which aren't worth speccing out. For example, navigating the page or adding an objectStore while inside a createObjectStore call.
This should probably be moved into the WebIDL spec.
The asynchronous API methods return without blocking the calling thread.
All asynchronous operations immediately return an IDBRequest instance.
This object does not initially contain any information about the result of the operation.
Once information becomes available, an event is fired on the request and the information becomes
available thorugh the properties of the IDBRequest instance.
IDBRequest Interface
The IDBRequest interface provides means to access results of
asynchronous requests to databases and database
objects using event handler attributes [DOM-LEVEL-3-EVENTS].
In the following example, we open a database asynchronously. Various event handlers are registered for responding to various situations.
interface IDBRequest : EventTarget {
readonly attribute any result getraises (IDBDatabaseException);
readonly attribute unsigned short errorCode getraises (IDBDatabaseException);
readonly attribute Object source;
readonly attribute IDBTransaction transaction;
const unsigned short LOADING = 1;
const unsigned short DONE = 2;
readonly attribute unsigned short readyState;
attribute Function onsuccess;
attribute Function onerror;
};
errorCode of type unsigned short, readonlyNOT_ALLOWED_ERR exception.
| Exception | On Get | On Set | Description | ||
|---|---|---|---|---|---|
IDBDatabaseException |
✔ | ✘ |
|
onerror of type Functiononsuccess of type FunctionreadyState of type unsigned short, readonlyLOADING,
otherwise returns DONE.result of type any, readonlyundefined when the request resulted in an error.
When the done flag is false, getting this property must throw a NOT_ALLOWED_ERR exception.
| Exception | On Get | On Set | Description | ||
|---|---|---|---|---|---|
IDBDatabaseException |
✔ | ✘ |
|
source of type Object, readonlytransaction of type IDBTransaction, readonlyDONE of type unsigned shortresult attribute.LOADING of type unsigned short
When a request is made, a new request is returned with its
readyState set to
LOADING.
If a request completes successfully, the
readyState
is changed to DONE, the
result
is set to the result of the request, and a event with type success is fired
at the request.
If an error occurs while performing the operation, the
readyState
is changed to DONE, the
errorCode
is set to the code of the error, and a event with type error is fired
at the request.
The setVersion function on IDBDatabase
uses a separate interface for its requests in order to make use of the
blocked event eaiser.
interface IDBVersionChangeRequest : IDBRequest {
attribute Function onblocked;
};
onblocked of type Functionblocked eventThe task source for these tasks is the database access task source.
This specification fires events with the following custom interfaces:
interface IDBVersionChangeEvent : Event {
readonly attribute DOMString version;
};
version of type DOMString, readonlyVERSION_CHANGE transaction.
Window and
WorkerUtils objects
must implement the IDBEnvironment interface.
Window implements IDBEnvironment;All instances of the Window type are defined to also implement the IDBEnvironment interface.
WorkerUtils implements IDBEnvironment;All instances of the WorkerUtils type are defined to also implement the IDBEnvironment interface.
[NoInterfaceObject]
interface IDBEnvironment {
readonly attribute IDBFactory indexedDB;
};
indexedDB of type IDBFactory, readonly
Every method for making asynchronous requests returns an
IDBRequest object that communicates back to the requesting
application through events.
This design means that any number of requests can be active on any database
or object handle at a time.
interface IDBFactory {
IDBRequest open (in DOMString name);
IDBRequest deleteDatabase (in DOMString name);
int cmp (in any first, in any second) raises (IDBDatabaseException);
};
cmpWhen invoked, this method must compare two keys. It'll return -1 if the first key is greater than the second, 1 if the first is less than the second, and 0 if the first is equal to the second.
This should probably take a collation parameter as well. In fact, it might make sense for this to be on the IDBDatabase, IDBObjectStore, and IDBIndex as well and do the comparison with their default collation.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| first | any |
✘ | ✘ | The first key to compare. |
| second | any |
✘ | ✘ | The second key to compare. |
| Exception | Description | ||
|---|---|---|---|
IDBDatabaseException |
|
intdeleteDatabase
When invoked, this method must create a request and return it. The created
request has no source.
The method then asynchronously runs the steps for deleting a database.
Let origin be the origin of the IDBEnvironment used to access
this IDBFactory and name be the name parameter passed
to this function.
If an error is returned from the steps above, the implementation must set the errorCode of the request to the code of the error returned and fire a error event at the request.
If the steps above are successful, the implementation must set the
result of the request
to null and fire a success event at
the request.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| name | DOMString |
✘ | ✘ | The name for the database |
IDBRequestopen
When invoked, this method must create a request and return it. The created
request has no source.
The method then asynchronously runs the steps for opening a database.
Let origin be the origin of the IDBEnvironment used to access
this IDBFactory and name be the name parameter passed
to this function.
If an error is returned from the steps above, the implementation must set the errorCode of the request to the code of the error returned and fire a error event at the request.
If the steps above are successful, the implementation must set the result of the request to the connection created by the steps above and fire a success event at the request.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| name | DOMString |
✘ | ✘ | The name for the database |
IDBRequestA database object can be used to manipulate the objects of that database. That is also the only way to obtaining a transaction for that database.
interface IDBDatabase : EventTarget {
readonly attribute DOMString name;
readonly attribute DOMString version;
readonly attribute DOMStringList objectStoreNames;
IDBObjectStore createObjectStore (in DOMString name, in optional Object optionalParameters) raises (IDBDatabaseException);
IDBRequest deleteObjectStore (in DOMString name) raises (IDBDatabaseException);
IDBVersionChangeRequest setVersion ([TreatNullAs=EmptyString] in DOMString version);
IDBTransaction transaction (in any storeNames, in optional unsigned short mode) raises (IDBDatabaseException);
void close ();
attribute Function onabort;
attribute Function onerror;
attribute Function onversionchange;
};
name of type DOMString, readonlyIDBDatabase instance. objectStoreNames of type DOMStringList, readonlyIDBDatabase instance, unless
setVersion and createObjectStore or deleteObjectStore
is called on this IDBDatabase instance itself. onabort of type Functiononerror of type Functiononversionchange of type Functionversion of type DOMString, readonlyIDBDatabase instance, unless setVersion is called on this
IDBDatabase instance itself. closevoidcreateObjectStore
This method creates and returns a new object store with the given name in the
connected database.
If this function is called from outside a VERSION_CHANGE transaction callback,
the implementation must throw a NOT_ALLOWED_ERR exception. If an objectStore with the same name already exists,
the implementation must throw a CONSTRAINT_ERR exception. Otherwise, the implementation must
create a new object store and return a IDBObjectStore object representing it.
If the optionalParameters argument is specified and has a keyPath property
which is not undefined or null, then set keyPath to the value
of this property. If keyPath is an Array, then each item in the array is
converted to a string. If keyPath is not an Array, it is converted to a
string.
If keyPath is an Array and any items in the array is not a valid key path,
or if keyPath is a string and is not a valid key path then a
NON_TRANSIENT_ERR error must be thrown. Otherwise set the created object store's
key path is set to the value of keyPath.
In some implementations it's possible for the implementation to asynchronously run into problems
creating the object store after the createObjectStore function has returned. For example in
implementations where metadata about the newly created objectStore is inserted into the database
asynchronously, or where the implementation might need to ask the user for permission for quota
reasons. Such implementations must still create and return a IDBObjectStore object. Instead,
once the implementation realizes that creating the objectStore has failed, it must abort the transaction
using the steps for aborting a transaction.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| name | DOMString |
✘ | ✘ | The name of a new object store |
| optionalParameters | Object |
✘ | ✔ | The options object whose attributes are optional parameters to this function.
Valid attributes are keyPath and autoIncrement.
keyPath specifies the key path of the new
object store.
If the attribute is null, undefined, or not present, no key path
is specified and thus keys are out-of-line.
autoIncrement specifies whether the object store created should have a
key generator.
It defaults to false. |
| Exception | Description | ||||||
|---|---|---|---|---|---|---|---|
IDBDatabaseException |
|
IDBObjectStoredeleteObjectStore
This method destroys the object store with the given name in the
connected database as well as
all indexes that are
referencing that object store.
Note that this method must only be called from a VERSION_CHANGE
transaction callback.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| name | DOMString |
✘ | ✘ | The name of an existing object store |
| Exception | Description | ||||
|---|---|---|---|---|---|
IDBDatabaseException |
|
IDBRequestsetVersionVERSION_CHANGE transaction
using the version argument as version and the IDBDatabase this function was called on as connection.
Return the IDBVersionChangeRequest returned by those steps.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| version | DOMString |
✘ | ✘ | The version to store in the database |
IDBVersionChangeRequesttransaction
This method, when called must execute the
steps for creating a transaction in a asychronous
fashion. The storeNames and mode arguments are
forwarded to the algorithm as-is. The callback argument is set to null.
The timeout argument is set to infinite.
The connection argument is set to the IDBDatabase that the
transaction() method was called on.
The method returns a IDBTransaction object representing the transaction
returned by the steps above.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| storeNames | any |
✘ | ✘ | The names of object stores and indexes in the scope of the new transaction |
| mode | unsigned short |
✘ | ✔ | The mode for isolating access to data inside the given
object stores.
If this parameter is not provided, the default access mode is READ_ONLY. |
| Exception | Description | ||||
|---|---|---|---|---|---|
IDBDatabaseException |
|
IDBTransactioninterface IDBObjectStore {
readonly attribute DOMString name;
readonly attribute DOMString keyPath;
readonly attribute DOMStringList indexNames;
readonly attribute IDBTransaction transaction;
IDBRequest put (in any value, in optional any key) raises (IDBDatabaseException, DOMException);
IDBRequest add (in any value, in optional any key) raises (IDBDatabaseException, DOMException);
IDBRequest delete (in any key) raises (IDBDatabaseException);
IDBRequest get (in any key) raises (IDBDatabaseException);
IDBRequest clear () raises (IDBDatabaseException);
IDBRequest openCursor (in optional any range, in optional unsigned short direction) raises (IDBDatabaseException);
IDBIndex createIndex (in DOMString name, in DOMString keyPath, in optional Object optionalParameters) raises (IDBDatabaseException);
IDBIndex index (in DOMString name) raises (IDBDatabaseException);
void deleteIndex (in DOMString indexName) raises (IDBDatabaseException);
};
indexNames of type DOMStringList, readonlykeyPath of type DOMString, readonlynull, the application must provide a key value for each modification operation.
name of type DOMString, readonlytransaction of type IDBTransaction, readonlyaddThis method throws a READ_ONLY_ERR if the transaction which this IDBObjectStore belongs to is has its mode set to READ_ONLY. If any of the following conditions are true, this method throws a DATA_ERR exception:
Array,
evaluating any of the items in their key path
on the value parameter yields a value and that value is not a valid key.
Otherwise this method creates a structured clone of the value parameter.
If this throws an exception that exception is rethrown. It then runs the steps for
asynchronously executing a request and returns the IDBRequest created by these steps.
The steps are run with this IDBObjectStore as source and the steps for
storing a record into an object store as operation, using this IDBObjectStore
as store, the created clone as value, the key parameter as
key, and with the no-overwrite flag flag set to true.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| value | any |
✘ | ✘ | The value to be stored in the record |
| key | any |
✘ | ✔ | The key used to identify the record |
| Exception | Description | ||||||
|---|---|---|---|---|---|---|---|
IDBDatabaseException |
|
||||||
| DOMException |
|
IDBRequestclearThis method throws a READ_ONLY_ERR if the transaction which this IDBObjectStore belongs to is has its mode set to READ_ONLY.
Otherwise this method runs the steps for asynchronously executing a request and returns the
IDBRequest created by these steps. The steps are run with this IDBObjectStore as
source and the steps for clearing an object store as operation, using
this IDBObjectStore as store.
| Exception | Description | ||||
|---|---|---|---|---|---|
IDBDatabaseException |
|
IDBRequestcreateIndex
This method creates and returns a new index with the given name and parameters in the
connected database. If this function is called from
outside a VERSION_CHANGE transaction callback, the implementation
must throw a NOT_ALLOWED_ERR exception. If an index with the same name already
exists, the implementation must throw a CONSTRAINT_ERR exception. Otherwise, the implementation
must create a new index and return a IDBIndex object representing it. The created
index has its unique and multirow flags are set to the values of the
unique and multirow properties in the optionalParameters argument.
If the keyPath argument is an Array, then each item in the array is
converted to a string. If keyPath is not an Array, it is converted to a
string.
If keyPath is an Array and any items in the array is not a valid key path,
or if keyPath is a string and is not a valid key path, or if keyPath is
and Array and the multirow property in the optionalParameters is true,
then a NON_TRANSIENT_ERR error must be thrown. Otherwise set the created object store's
key path is set to the value of keyPath.
The index that is requested to be created can contain constraints on the data allowed in the index's
referenced object store, such as requiring uniqueness of the values referenced by the
index's keyPath. If the referenced object store already contains data which violates these
constraints, this must not cause the implementation of createIndex to throw an exception or affect what it returns.
The implementation must still create and return a IDBIndex object.
Instead the implementation must asynchronously abort the VERSION_CHANGE
transaction which was used for the createIndex call.
In some implementations it's possible for the implementation to asynchronously run into problems
creating the index after the createIndex function has returned. For example in
implementations where metadata about the newly created index is inserted into the database
asynchronously, or where the implementation might need to ask the user for permission for quota
reasons. Such implementations must still create and return a IDBIndex object. Instead,
once the implementation realizes that creating the index has failed, it must abort the transaction
using the steps for aborting a transaction.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| name | DOMString |
✘ | ✘ | The name of a new index |
| keyPath | DOMString |
✘ | ✘ | The key path used by the new index |
| optionalParameters | Object |
✘ | ✔ | The options object whose attributes are optional parameters to this function.
The valid options are unique and multirow. unique specifies whether the index's
unique flag is set. It defaults to false.
multirow specifies whether the index's multirow flag is set.
It defaults to false. |
| Exception | Description | ||||||
|---|---|---|---|---|---|---|---|
IDBDatabaseException |
|
IDBIndexdeleteThis method throws a READ_ONLY_ERR if the transaction which this IDBObjectStore belongs to is has its mode set to READ_ONLY. If the key parameter is not a valid key this method throws a DATA_ERR exception.
Otherwise this method runs the steps for
asynchronously executing a request and returns the IDBRequest created by these steps.
The steps are run with this IDBObjectStore as source and the steps for deleting
a record from an object store as operation, using this IDBObjectStore
as store and the key parameter as key.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| key | any |
✘ | ✘ | Key identifying the record to be deleted |
| Exception | Description | ||||
|---|---|---|---|---|---|
IDBDatabaseException |
|
IDBRequestdeleteIndex
This method destroys the index with the given name in the
connected database. Note that this
method must only be called from a VERSION_CHANGE
transaction callback.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| indexName | DOMString |
✘ | ✘ | The name of an existing index |
| Exception | Description | ||||
|---|---|---|---|---|---|
IDBDatabaseException |
|
voidget
If the key parameter is not a valid key or a key range, this method
throws a DATA_ERR exception. Otherwise, this method runs the steps for asynchronously executing
a request and returns the IDBRequest created by these steps. The steps are run with this
IDBObjectStore as source and the steps for retrieving a value from an
object store as operation, using this IDBObjectStore as store and the
key parameter as key.
This function produces the same result if a record with the given key doesn't exist as when a record
exists, but has undefined as value. If you need to tell the two situations apart, you can use
openCursor with the same key. This will return a cursor with
undefined as value if a record exists, or no cursor if no such record exists.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| key | any |
✘ | ✘ | Key identifying the record to be retrieved.
This can also be a IDBKeyRange in which case the function retreives the first existing value in that range. |
| Exception | Description | ||||
|---|---|---|---|---|---|
IDBDatabaseException |
|
IDBRequestindexIDBIndex representing a index that is part of the
to this object store. Every call to this function on the same
IDBObjectStore instance and with the same name returns the same IDBIndex instance.
However the retured IDBIndex instance is specific to this IDBObjectStore instance. If this
function is called on a different IDBObjectStore instance, a different IDBIndex instance is
returned. A result of this is that different IDBTransactions use different IDBIndex instances
to represent the same index.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| name | DOMString |
✘ | ✘ | The name of an existing index |
| Exception | Description | ||
|---|---|---|---|
IDBDatabaseException |
|
IDBIndexopenCursor
If the range parameter is specified but is not a valid key or a key range,
this method throws a DATA_ERR exception. Otherwise, this method creates a cursor. The cursor
must implement the IDBCursorWithValue interface.
The newly created cursor must have an undefined position, a direction set to the value
of the direction parameter, false as iterable flag value, and undefined
key and value. The source
of the cursor is the IDBObjectStore this function was called on.
If the range parameter is a key range then the cursor's range must be set to that range. Otherwise, if the range parameter is a valid key then the cursor's range is set to key range containing only that key value. If the range parameter is not specified, the cursor's key range is left as undefined.
This method runs the steps for asynchronously executing a request and returns the IDBRequest
created by these steps. The steps are run with this IDBObjectStore as source and the
steps for iterating a cursor as operation,
using the created cursor as cursor and with undefined as key.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| range | any |
✘ | ✔ | The key range to use as the cursor's range |
| direction | unsigned short |
✘ | ✔ | The cursor's required direction |
| Exception | Description | ||||
|---|---|---|---|---|---|
IDBDatabaseException |
|
IDBRequestputThis method throws a READ_ONLY_ERR if the transaction which this IDBObjectStore belongs to is has its mode set to READ_ONLY. If any of the following conditions are true, this method throws a DATA_ERR exception:
Array,
evaluating any of the items in their key path
on the value parameter yields a value and that value is not a valid key.
Otherwise this method creates a structured clone of the value parameter.
If this throws an exception that exception is rethrown. It then runs the steps for
asynchronously executing a request and returns the IDBRequest created by these steps.
The steps are run with this IDBObjectStore as source and the steps for
storing a record into an object store as operation, using this IDBObjectStore
as store, the created clone as value, the key parameter as
key, and with the no-overwrite flag flag set to false.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| value | any |
✘ | ✘ | The value to be stored in the record |
| key | any |
✘ | ✔ | The key used to identify the record |
| Exception | Description | ||||||
|---|---|---|---|---|---|---|---|
IDBDatabaseException |
|
||||||
| DOMException |
|
IDBRequestIndex objects implement the following interface:
interface IDBIndex {
readonly attribute DOMString name;
readonly attribute IDBObjectStore objectStore;
readonly attribute DOMString keyPath;
readonly attribute boolean unique;
IDBRequest openCursor (in optional IDBKeyRange range, in optional unsigned short direction) raises (IDBDatabaseException);
IDBRequest openKeyCursor (in optional IDBKeyRange range, in optional unsigned short direction) raises (IDBDatabaseException);
IDBRequest get (in any key) raises (IDBDatabaseException);
IDBRequest getKey (in any key) raises (IDBDatabaseException);
};
keyPath of type DOMString, readonlynull, this index is not auto-populated. name of type DOMString, readonlyobjectStore of type IDBObjectStore, readonlyIDBObjectStore instance for the
referenced object store in this IDBIndex's transaction.
This must return the same IDBObjectStore instance as was used to get a reference to this
IDBIndex. unique of type boolean, readonlyget
If the key parameter is not a valid key or a key range, this method
throws a DATA_ERR exception. This method runs the steps for asynchronously executing a request
and returns the IDBRequest created by these steps. The steps are run with this
IDBObjectStore as source and the steps for retrieving a referenced value from an
index as operation, using this IDBIndex as index and the
key parameter as key.
This function produces the same result if a record with the given key doesn't exist as when a record
exists, but has undefined as value. If you need to tell the two situations apart, you can use
openCursor with the same key. This will return a cursor with
undefined as value if a record exists, or no cursor if no such record exists.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| key | any |
✘ | ✘ | Key identifying the record to be retrieved.
This can also be a IDBKeyRange in which case the function retreives the first existing value in that range. |
| Exception | Description | ||||
|---|---|---|---|---|---|
IDBDatabaseException |
|
IDBRequestgetKey
If the key parameter is not a valid key or a key range, this method
throws a DATA_ERR exception. This method runs the steps for asynchronously executing a request
and returns the IDBRequest created by these steps. The steps are run with this
IDBObjectStore as source and the steps for retrieving a value from an
index as operation, using this IDBIndex as index and the
key parameter as key.
This function produces the same result if a record with the given key doesn't exist as when a record
exists, but has undefined as value. If you need to tell the two situations apart, you can use
openKeyCursor with the same key. This will return a cursor with
undefined as value if a record exists, or no cursor if no such record exists.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| key | any |
✘ | ✘ | Key identifying the record to be retrieved. This can also be a IDBKeyRange in which case
the function retreives the first existing value in that range. |
| Exception | Description | ||||
|---|---|---|---|---|---|
IDBDatabaseException |
|
IDBRequestopenCursor
If the range parameter is specified but is not a valid key or a key range,
this method throws a DATA_ERR exception. Otherwise, this method creates a cursor. The cursor
must implement the IDBCursorWithValue interface.
The newly created cursor must have an undefined position, a direction set to the value
of the direction parameter, false as iterable flag value, and undefined
key and value. The source
of the cursor is the IDBIndex this function was called on.
If the range parameter is a key range then the cursor's range is set to that range. Otherwise, if the range parameter is a valid key then the cursor's range is set to key range containing only that key value. If the range parameter is not specified, the cursor's key range is left as undefined.
This method runs the steps for asynchronously executing
a request and returns the IDBRequest created by these steps. The steps are run with this
IDBIndex as source and the steps for iterating a cursor as operation,
using the created cursor as cursor and with undefined as key
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| range | |
✘ | ✔ | The key range to use as the cursor's range |
| direction | unsigned short |
✘ | ✔ | The cursor's required direction |
| Exception | Description | ||||
|---|---|---|---|---|---|
IDBDatabaseException |
|
IDBRequestopenKeyCursor
If the range parameter is specified but is not a valid key or a key range,
this method throws a DATA_ERR exception. Otherwise, this method creates a cursor.
The cursor must implement the IDBCursor interface,
but must not implement the IDBCursorWithValue interface.
The newly created cursor must have an undefined position,
a direction set to the value of the direction parameter, false as iterable flag value,
and undefined key and value.
The source
of the cursor is the IDBIndex this function was called on.
If the range parameter is a key range then the cursor's range is set to that range. Otherwise, if the range parameter is a valid key then the cursor's range is set to key range containing only that key value. If the range parameter is not specified, the cursor's key range is left as undefined.
This method runs the steps for asynchronously executing
a request and returns the IDBRequest created by these steps. The steps are run with this
IDBObjectStore as source and the steps for iterating a cursor as operation,
using the created cursor as cursor and with undefined as key
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| range | |
✘ | ✔ | The key range to use as the cursor's range |
| direction | unsigned short |
✘ | ✔ | The cursor's required direction |
| Exception | Description | ||||
|---|---|---|---|---|---|
IDBDatabaseException |
|
IDBRequestCursor objects implement the following interface:
interface IDBCursor {
const unsigned short NEXT = 0;
const unsigned short NEXT_NO_DUPLICATE = 1;
const unsigned short PREV = 2;
const unsigned short PREV_NO_DUPLICATE = 3;
readonly attribute Object source;
readonly attribute unsigned short direction;
readonly attribute any key;
readonly attribute any primaryKey;
IDBRequest update (in any value) raises (IDBDatabaseException, DOMException);
void advance (in int count);
void continue (in optional any key) raises (IDBDatabaseException);
IDBRequest delete () raises (IDBDatabaseException);
};
direction of type unsigned short, readonlykey of type any, readonlyundefined.
I.e. if it's currently being iterated or has iterated past the end of its range.primaryKey of type any, readonlyundefined.
I.e. if it's currently being iterated or has iterated past the end of its range.source of type Object, readonlyIDBObjectStore or IDBIndex
which this cursor is iterating. This function never returns null or throws an exception, even if the is currently being iterated, has iterated past its end,
or its transaction is not active. advanceThis method runs the steps for asynchronously executing a request. However, the steps are slightly modified such that instead of creating a new IDBRequest, it reuses the request originally created when this cursor was created. The done flag on the request is set to false before the request is returned. The steps are run with the cursor's source as source. The operation runs the steps for iterating a cursor count number of times with null as key and this cursor as cursor.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| count | int |
✘ | ✘ | The number of advances forward the cursor should make. |
voidcontinueIf this cursor's got value flag is false, this method throws a NOT_ALLOWED_ERR. If the key parameter is specified and fulfills any of these conditions this method must throw a DATA_ERR exception:
Otherwise this method runs the steps for asynchronously executing a request. However, the steps are slightly modified such that instead of creating a new IDBRequest, it reuses the request originally created when this cursor was created. The done flag on the request is set to false before the request is returned. The steps are run with the cursor's source as source and the steps for iterating a cursor as operation, using this cursor as cursor and the key parameter as key.
Before this method returns, unless an exception was thrown, it sets the got value flag on the cursor to false.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| key | any |
✘ | ✔ | The next key to position this cursor at |
| Exception | Description | ||||||
|---|---|---|---|---|---|---|---|
IDBDatabaseException |
|
voiddelete
This method throws a READ_ONLY_ERR if the transaction which this IDBCursor belongs to
has its mode set to READ_ONLY. If this cursor's got value flag is false,
or if this cursor was created using
openKeyCursor a
NOT_ALLOWED_ERR is thrown.
Otherwise this method runs the steps for asynchronously executing a request and returns the
IDBRequest created by these steps.
The steps are run with this IDBCursor as source
and the steps for deleting a record from an object store as operation, using this cursor's
effective object store and effective key as store and
key respectively.
This method used to set this cursor's value to null. Do we want to keep that?
| Exception | Description | ||||||
|---|---|---|---|---|---|---|---|
IDBDatabaseException |
|
IDBRequestupdate
This method throws a READ_ONLY_ERR if the transaction which this IDBCursor belongs to
has its mode set to READ_ONLY. If this cursor's got value flag is false or if this
cursor was created using
openKeyCursor. This method
throws a NOT_ALLOWED_ERR. If the effective object store of this cursor uses in-line
keys and evaluating the
key path
of the value parameter results in a different value than the cursor's effective key,
this method throws DATA_ERR.
Otherwise this method creates a structured clone of the value parameter.
If this throws an exception that exception is rethrown. It then runs the steps for
asynchronously executing a request and returns the IDBRequest created by these steps.
The steps are run with this IDBCursor as source and the steps for
storing a record into an object store as operation, using this cursor's
effective object store as store, the created clone as value,
this cursor's effective key as key, and with the no-overwrite flag
flag set to false.
A result of running the steps for storing a record into an object store is that if the record has been deleted since the cursor moved to it, a new record will be created.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| value | any |
✘ | ✘ | The new value to store at the current position. |
| Exception | Description | ||||||||
|---|---|---|---|---|---|---|---|---|---|
IDBDatabaseException |
|
||||||||
| DOMException |
|
IDBRequestNEXT of type unsigned shortNEXT_NO_DUPLICATE of type unsigned shortPREV of type unsigned shortPREV_NO_DUPLICATE of type unsigned shortinterface IDBCursorWithValue : IDBCursor {
readonly attribute any value;
};
value of type any, readonlyundefined. I.e. if it's currently being iterated or has
iterated past the end of its range. Note that if this property returns an object, it returns the same
object instance every time it is inspected, until the cursor is iterated. This means that if the object is modified,
those modifications will be seen by anyone inspecting the value of the cursor. However modifying such an object
does not modify the contents of the database.Transaction objects implement the following interface:
interface IDBTransaction : EventTarget {
const unsigned short READ_ONLY = 0;
const unsigned short READ_WRITE = 1;
const unsigned short VERSION_CHANGE = 2;
readonly attribute unsigned short mode;
readonly attribute IDBDatabase db;
IDBObjectStore objectStore (in DOMString name) raises (IDBDatabaseException);
void abort () raises (IDBDatabaseException);
attribute Function onabort;
attribute Function oncomplete;
attribute Function onerror;
};
db of type IDBDatabase, readonlymode of type unsigned short, readonlyonabort of type Functiononcomplete of type Functiononerror of type Functionabort| Exception | Description | ||
|---|---|---|---|
IDBDatabaseException |
|
voidobjectStoreIDBObjectStore representing a object store that is part of the
to the scope of this transaction. Every call to this function on the same
IDBTransaction instance and with the same name returns the same
IDBObjectStore instance.
However the returned IDBObjectStore instance is specific to this
IDBTransaction.
If this function is called on a different IDBTransaction, a different
IDBObjectStore instance is returned.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| name | DOMString |
✘ | ✘ | The requested object store |
| Exception | Description | ||
|---|---|---|---|
IDBDatabaseException |
|
IDBObjectStoreREAD_ONLY of type unsigned shortREAD_WRITE of type unsigned shortVERSION_CHANGE of type unsigned shortsetVersion() method of
IDBDatabase.The synchronous database API methods provide a blocking access pattern to IndexedDB databases. Since they block the calling thread they are only available from workers.
WorkerUtils objects must implement the
IDBEnvironmentSync interface.
WorkerUtils implements IDBEnvironmentSync;[NoInterfaceObject]
interface IDBEnvironmentSync {
readonly attribute IDBFactorySync indexedDBSync;
};
indexedDBSync of type IDBFactorySync, readonlyinterface IDBFactorySync {
IDBDatabaseSync open (in DOMString name);
void deleteDatabase (in DOMString name);
};
deleteDatabase
When invoked, this method synchronously runs the steps for deleting a database.
Let origin be the origin of the IDBEnvironmentSync used to access
this IDBFactorySync and name be the name argument passed
to this function.
If an error is returned from the steps above, then the implementation must
throw an IDBDatabaseException with its
code
and message set to
appropriate values for the error.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| name | DOMString |
✘ | ✘ | The name of the database to be deleted. |
voidopen
When invoked, this method synchronously runs the steps for opening a database.
Let origin be the origin of the IDBEnvironmentSync used to access
this IDBFactorySync and name be the name argument passed
to this function.
If an error is returned from the steps above, then the implementation must
throw an IDBDatabaseException with its
code
and message set to
appropriate values for the error.
If the steps above are successful, the implementation must create a IDBDatabaseSync object representing the created connection and return it.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| name | DOMString |
✘ | ✘ | The name for the database |
IDBDatabaseSyncA database object provides access to the schema and data of a particular database.
interface IDBDatabaseSync {
readonly attribute DOMString name;
readonly attribute DOMString version;
readonly attribute DOMStringList objectStoreNames;
IDBObjectStoreSync createObjectStore (in DOMString name, in optional Object optionalParameters) raises (IDBDatabaseException);
void deleteObjectStore (in DOMString name) raises (IDBDatabaseException);
IDBTransactionSync setVersion ([TreatNullAs=EmptyString] in DOMString version);
void transaction (in any storeNames, in IDBTransactionCallback callback, in optional unsigned short mode, in optional unsigned long timeout) raises (IDBDatabaseException);
void close ();
};
name of type DOMString, readonlyIDBDatabaseSync instance.
objectStoreNames of type DOMStringList, readonlyIDBDatabaseSync instance, unless
setVersion and
createObjectStore or
deleteObjectStore
is called on this IDBDatabaseSync instance itself.
version of type DOMString, readonlyIDBDatabaseSync instance,
unless setVersion is called
on this IDBDatabaseSync instance itself.
closevoidcreateObjectStore
This method creates a and returns a new object store with the
given name in the connected database. This method
should only be called from inside a VERSION_CHANGE transaction.
If the optionalParameters argument is specified and has a keyPath property
which is not undefined or null, then set keyPath to the value
of this property. If keyPath is an Array, then each item in the array is
converted to a string. If keyPath is not an Array, it is converted to a
string.
If keyPath is an Array and any items in the array is not a valid key path,
or if keyPath is a string and is not a valid key path then a
NON_TRANSIENT_ERR error must be thrown. Otherwise set the created object store's
key path is set to the value of keyPath.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| name | DOMString |
✘ | ✘ | The name of a new object store |
| optionalParameters | Object |
✘ | ✔ | The options object whose attributes are optional parameters to this function.
Valid attributes are keyPath and autoIncrement. keyPath specifies the
key path of the new object store.
If the attribute is null, undefined, the empty string, or not present, no
key path is specified and thus keys are
out-of-line. autoIncrement specifies whether the
object store created should have a key generator.
It defaults to false. |
| Exception | Description | ||||||
|---|---|---|---|---|---|---|---|
IDBDatabaseException |
|
IDBObjectStoreSyncdeleteObjectStore
This method destroys an object store with the
given name as well as all indexes that are
referencing that object store. This method
should only be called from inside a VERSION_CHANGE transaction.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| name | DOMString |
✘ | ✘ | The name of an existing object store |
| Exception | Description | ||||
|---|---|---|---|---|---|
IDBDatabaseException |
|
voidsetVersionVERSION_CHANGE transaction using
the version argument as version and the IDBDatabaseSync
this function was called on as connection. It returns the transaction
object that should be used to perform the changes to the database required for the new version.
Processing a setVersion call may take a long time as it requires all other connections to the database to be closed, which in turn may depend on user input or other long-running tasks. If blocking for a long period of time is not acceptable for a given scenario then the asynchronous API should be used for version changes.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| version | DOMString |
✘ | ✘ | The version to store in the database |
IDBTransactionSynctransaction
This method, when called must execute the
steps for creating a transaction in a sychronous
fashion. The storeNames, callback, mode, and
timeout arguments are forwarded to the algorithm as-is. The connection
argument is set to the IDBDatabaseSync that the transaction() method was
called on.
The method returns a IDBTransactionSync object representing the transaction
returned by the steps above.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| storeNames | any |
✘ | ✘ | The names of object stores and indexes in the scope of the new transaction |
| callback | |
✘ | ✘ | A callback which will be called with the newly created transaction. When the callback returns, the transaction is committed. |
| mode | unsigned short |
✘ | ✔ | The mode for isolating access to data inside the given
object stores. If this parameter is not provided, the default access
mode is READ_ONLY. |
| timeout | unsigned long |
✘ | ✔ | The interval in milliseconds which this operation is allowed to take to reserve all the database objects identified in the new transaction's scope. The default is user agent specific |
| Exception | Description | ||||||
|---|---|---|---|---|---|---|---|
IDBDatabaseException |
|
void[NoInterfaceObject, Callback=FunctionOnly]
interface IDBTransactionCallback {
void handleEvent (in IDBTransactionSync transaction);
};
handleEvent
The transaction that was just started.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| transaction | |
✘ | ✘ |
voidIn the following example, we set up an object store to use the key path id. This object store is also designed to use a key generator.
var db = indexedDBSync.open('AddressBook');
if (db.version !== '1') {
var vtx = db.setVersion('1');
vtx.createObjectStore('Contact', 'id', true);
}
The scenario above doesn't actually work well because you have to unwind to the event loop to get the version transaction to commit before you can do something else. Leaving it like this for now, as this will get sorted out when we add callbacks for transactions in the sync API (we'll have to do it for the setVersion transaction as well).
Using this database, we can store records in the Contact object store.
var tx = db.transaction();
var store = tx.objectStore('Contact');
var contact = store.add({name: 'Lincoln', number: '7012'});
// contact.id === 1
A stored value can be retrieved using the same key used by the first put operation.
var contact = store.get(1);
// contact.name === 'Lincoln'A put operation will overwrite the record stored by the first add operation with the same key.
var abraham = {id: 1, name: 'Abraham', number: '2107'};
store.put(abraham);Now when the object store is read with the same key, the result is different compared to the object read earlier.
var contact = store.get(1);
// contact.id === 1 && contact.name === 'Abraham';Additionally, all the records of an object store matching a certain key range can be retrieved in key order.
var range = new IDBKeyRange.bound(2, 4);
var cursor = store.openCursor(range);
// each value is a contact and each key is the id for that
// contact whose id is between 2 and 4, both inclusive
cursor.continue();interface IDBObjectStoreSync {
readonly attribute DOMString name;
readonly attribute DOMString keyPath;
readonly attribute DOMStringList indexNames;
readonly attribute IDBTransactionSync transaction;
any put (in any value, in optional any key) raises (IDBDatabaseException, DOMException);
any add (in any value, in optional any key) raises (IDBDatabaseException, DOMException);
void delete (in any key) raises (IDBDatabaseException);
any get (in any key) raises (IDBDatabaseException);
void clear () raises (IDBDatabaseException);
IDBIndexSync createIndex (in DOMString name, in DOMString keyPath, in optional Object optionalParameters) raises (IDBDatabaseException);
IDBIndexSync index (in DOMString name) raises (IDBDatabaseException);
void deleteIndex (in DOMString indexName) raises (IDBDatabaseException);
IDBCursorWithValueSync openCursor (in optional any range, in optional unsigned short direction) raises (IDBDatabaseException);
};
indexNames of type DOMStringList, readonlykeyPath of type DOMString, readonlynull,
the application must provide a key value for each modification operation.
name of type DOMString, readonlytransaction of type IDBTransactionSync, readonlyadd
This method throws a READ_ONLY_ERR if the transaction which this IDBObjectStoreSync belongs to is
has its mode set to READ_ONLY. If any of the following conditions are true, this method
throws a DATA_ERR exception:
Array,
evaluating any of the items in their key path
on the value parameter yields a value and that value is not a valid key.
Otherwise this method creates a structured clone of the value parameter.
If this throws an exception that exception is rethrown. It then runs the steps for
synchronously executing a request and returns the key of the stored object.
The steps are run with this IDBObjectStoreSync as source and the steps for
storing a record into an object store as operation, using this IDBObjectStoreSync
as store, the created clone as value, the key parameter as
key, and with the no-overwrite flag flag set to true.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| value | any |
✘ | ✘ | The value to be stored in the record |
| key | any |
✘ | ✔ | The key used to identify the record |
| Exception | Description | ||||||||
|---|---|---|---|---|---|---|---|---|---|
IDBDatabaseException |
|
||||||||
| DOMException |
|
anyclear
This method throws a READ_ONLY_ERR if the transaction which this IDBObjectStoreSync belongs to is
has its mode set to READ_ONLY.
Otherwise this method runs the steps for synchronously executing a request. The steps
are run with this IDBObjectStoreSync as source and the
steps for clearing an object store as operation, using
this IDBObjectStoreSync as store.
| Exception | Description | ||||
|---|---|---|---|---|---|
IDBDatabaseException |
|
voidcreateIndex
This creates and returns a new index with the given name and parameters in the
connected database. Note that this method must only
be called from a VERSION_CHANGE transaction. The created
index has its unique and multirow flags are set to the values of the
unique and multirow properties in the optionalParameters argument.
If the keyPath argument is an Array, then each item in the array is
converted to a string. If keyPath is not an Array, it is converted to a
string.
If keyPath is an Array and any items in the array is not a valid key path,
or if keyPath is a string and is not a valid key path, or if keyPath is
and Array and the multirow property in the optionalParameters is true,
then a NON_TRANSIENT_ERR error must be thrown. Otherwise set the created object store's
key path is set to the value of keyPath.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| name | DOMString |
✘ | ✘ | The name of a new index |
| keyPath | DOMString |
✘ | ✘ | The key path used by the new index |
| optionalParameters | Object |
✘ | ✔ | The options object whose attributes are optional parameters to this function.
The valid options are unique and multirow. unique specifies whether the index's
unique flag is set. It defaults to false. multirow specifies whether the
index's multirow flag is set. It defaults to false. |
| Exception | Description | ||||||
|---|---|---|---|---|---|---|---|
IDBDatabaseException |
|
IDBIndexSyncdelete
This method throws a READ_ONLY_ERR if the transaction which this IDBObjectStoreSync belongs to is
has its mode set to READ_ONLY. If the key parameter is not a valid key
this method throws a DATA_ERR exception.
Otherwise this method runs the steps for
synchronously executing a request.
The steps are run with this IDBObjectStoreSync as source and the
steps for deleting
a record from an object store as operation, using this IDBObjectStoreSync
as store and the key parameter as key.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| key | any |
✘ | ✘ | Key identifying the record to be deleted |
| Exception | Description | ||||||
|---|---|---|---|---|---|---|---|
IDBDatabaseException |
|
voiddeleteIndex
This method destroys the index with the given name in the
connected database. Note that this
method must only be called from a VERSION_CHANGE
transaction.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| indexName | DOMString |
✘ | ✘ | The name of an existing index |
| Exception | Description | ||||
|---|---|---|---|---|---|
IDBDatabaseException |
|
voidget
If the key parameter is not a valid key or a key range, this method
throws a DATA_ERR exception. Otherwise, this method runs the steps for synchronously executing
a request and returns the result of the operation. The steps are run with this
IDBObjectStoreSync as source and the
steps for retrieving a value from an
object store as operation, using this IDBObjectStoreSync as store and the
key parameter as key.
This function produces the same result if a record with the given key doesn't exist as when a record
exists, but has undefined as value. If you need to tell the two situations apart, you can use
openCursor with the same key. This will return a cursor with
undefined as value if a record exists, or no cursor if no such record exists.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| key | any |
✘ | ✘ | Key identifying the record to be retrieved.
This can also be a IDBKeyRange in which case the function retrieves the first existing value in that range. |
| Exception | Description | ||||
|---|---|---|---|---|---|
IDBDatabaseException |
|
anyindexIDBIndexSync representing a index that is part of the
to this object store. Every call to this function on the same
IDBObjectStoreSync instance and with the same name returns the same
IDBIndexSync instance. However the retured
IDBIndexSync instance is specific to this
IDBObjectStoreSync instance. If this function is called on a different
IDBObjectStoreSync instance, a different IDBIndexSync
instance is returned. A result of this is that different IDBTransactionSyncs use different
IDBIndexSync instances to represent the same index.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| name | DOMString |
✘ | ✘ | The name of an existing index |
| Exception | Description | ||
|---|---|---|---|
IDBDatabaseException |
|
IDBIndexSyncopenCursor
If the range parameter is specified but is not a valid key or a key range,
this method throws a DATA_ERR exception. Otherwise, this method creates a cursor. The cursor
must implement the IDBCursorWithValueSync interface.
The newly created cursor must have an undefined position, a direction set to the value
of the direction parameter, false as iterable flag value, and undefined
key and value. The source
of the cursor is the IDBObjectStoreSync this function was called on.
If the range parameter is a key range then the cursor's range is set to that range. Otherwise, if the range parameter is a valid key then the cursor's range is set to key range containing only that key value. If the range parameter is not specified, the cursor's key range is left as undefined.
This method runs the steps for synchronously executing a request and returns the result of the operation, in
this case an IDBCursorSync object. The steps are run with this IDBObjectStoreSync as source and the
steps for iterating a cursor as operation,
using the created cursor as cursor and with undefined as key.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| range | any |
✘ | ✔ | The key range to use as the cursor's range |
| direction | unsigned short |
✘ | ✔ | The cursor's required direction |
| Exception | Description | ||||
|---|---|---|---|---|---|
IDBDatabaseException |
|
IDBCursorWithValueSyncput
This method throws a READ_ONLY_ERR if the transaction which this IDBObjectStoreSync belongs to
has its mode set to READ_ONLY. If any of the following conditions are true, this method throws a DATA_ERR exception:
Array,
evaluating any of the items in their key path
on the value parameter yields a value and that value is not a valid key.
Otherwise this method creates a structured clone of the value parameter.
If this throws an exception that exception is rethrown. It then runs the steps for
synchronously executing a request and returns the result, in this case the key of the stored object.
The steps are run with this IDBObjectStoreSync as source and the steps for
storing a record into an object store as operation, using this IDBObjectStoreSync
as store, the created clone as value, the key parameter as
key, and with the no-overwrite flag flag set to false.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| value | any |
✘ | ✘ | The value to be stored in the record |
| key | any |
✘ | ✔ | The key used to identify the record |
| Exception | Description | ||||||||
|---|---|---|---|---|---|---|---|---|---|
IDBDatabaseException |
|
||||||||
| DOMException |
|
anyAn index can be created for retrieving records other than by using record keys. Continuing the earlier example, an index could be maintained on the name property of objects in the Contact object store.
var db = indexedDBSync.open('AddressBook');
if (db.version === '1') {
var vtx = db.setVersion('2');
var store = vtx.objectStore('Contact');
store.createIndex('ContactName', 'name', false);
}The scenario above doesn't actually work well because you have to unwind to the event loop to get the version transaction to commit before you can do something else. Leaving it like this for now, as this will get sorted out when we add callbacks for transactions in the sync API (we'll have to do it for the setVersion transaction as well).
For example, the id of an object with the name property value 'Lincoln' can be retrieved using the ContactName index.
Additionally, all the records of an object store matching a certain range index keys can be retrieved in key order. When objects are retrieved from the Contact object store, they are arranged by the value of the id attribute. On the other hand, when objects are retrieved using the ContactName index, they are arranged by the value of the name property.
var range = new IDBKeyRange.bound('L', 'M');
var cursor = index.openCursor(range);
// each value is a contact and each key is the name for that
// contact whose name's first letter is either L or M
cursor.continue();If, on the other hand, we only want the names and keys but not the whole Contact objects for a given range, then we can use a different mechanism for that.
var range = new IDBKeyRange.bound('L', 'M');
var cursor = index.openKeyCursor(range);
// each value is a contact id and each key is the name for that
// contact whose name's first letter is either L or M
cursor.continue();interface IDBIndexSync {
readonly attribute DOMString name;
readonly attribute IDBObjectStoreSync objectStore;
readonly attribute DOMString keyPath;
readonly attribute boolean unique;
IDBCursorWithValueSync openCursor (in optional IDBKeyRange range, in optional unsigned short direction) raises (IDBDatabaseException);
IDBCursorSync openKeyCursor (in optional IDBKeyRange range, in optional unsigned short direction) raises (IDBDatabaseException);
any get (in any key) raises (IDBDatabaseException);
any getKey (in any key) raises (IDBDatabaseException);
};
keyPath of type DOMString, readonlynull, this
index is not auto-populated.
name of type DOMString, readonlyobjectStore of type IDBObjectStoreSync, readonlyIDBObjectStoreSync instance for the
referenced object store in this IDBIndexSync's transaction.
This must return the same IDBObjectStoreSync instance as was used to get a reference
to this IDBIndexSync.
unique of type boolean, readonlyget
If the key parameter is not a valid key or a key range, this method
throws a DATA_ERR exception. This method runs the steps for synchronously executing a request
and returns the result from that, in this case an object from the underlying store.
The steps are run with this IDBIndexSync as source and the
steps
for retrieving a referenced value from an index as operation, using this IDBIndexSync
as index and the key parameter as key.
This function produces the same result if a record with the given key doesn't exist as when a record
exists, but has undefined as value. If you need to tell the two situations apart, you can use
openCursor with the same key. This will return a cursor with
undefined as value if a record exists, or no cursor if no such record exists.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| key | any |
✘ | ✘ | Key identifying the record to be retrieved. This can also be a IDBKeyRange in which case
the function retreives the first existing value in that range. |
| Exception | Description | ||||
|---|---|---|---|---|---|
IDBDatabaseException |
|
anygetKey
If the key parameter is not a valid key or a key range, this method
throws a DATA_ERR exception. This method runs the steps for synchronously executing a request
and returns the result from that, in this case an index value (a key).
The steps are run with the IDBObjectStoreSync associated with this index as source and the
steps for retrieving a value from an index as operation, using this
IDBIndexSync as index and the key parameter as key.
This function produces the same result if a record with the given key doesn't exist as when a record
exists, but has undefined as value. If you need to tell the two situations apart, you can use
openCursor with the same key. This will return a cursor with
undefined as value if a record exists, or no cursor if no such record exists.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| key | any |
✘ | ✘ | Key identifying the record to be retrieved. This can also be a IDBKeyRange in which case
the function retreives the first existing value in that range. |
| Exception | Description | ||||
|---|---|---|---|---|---|
IDBDatabaseException |
|
anyopenCursor
If the range parameter is specified but is not a valid key or a key range,
this method throws a DATA_ERR exception. Otherwise, this method creates a cursor.
The cursor must implement the IDBCursorWithValueSync interface.
The newly created cursor must have an undefined position,
a direction set to the value of the direction parameter, false as iterable flag value, and undefined
key and value.
The source
of the cursor is the IDBIndexSync this function was called on.
If the range parameter is a key range then the cursor's range is set to that range. Otherwise, if the range parameter is a valid key then the cursor's range is set to key range containing only that key value. If the range parameter is not specified, the cursor's key range is left as undefined.
This method runs the steps for synchronously executing
a request and returns the result, in this case a cursor object. The steps are run with this
IDBIndexSync as source and the steps for iterating a cursor as operation,
using the created cursor as cursor and with undefined as key
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| range | |
✘ | ✔ | The key range to use as the cursor's range |
| direction | unsigned short |
✘ | ✔ | The cursor's required direction |
| Exception | Description | ||||
|---|---|---|---|---|---|
IDBDatabaseException |
|
IDBCursorWithValueSyncopenKeyCursor
If the range parameter is specified but is not a valid key or a key range,
this method throws a DATA_ERR exception. Otherwise, this method creates a cursor. The cursor
must implement the IDBCursorSync interface and
must not implement the IDBCursorWithValueSync interface.
The newly created cursor must have an undefined position, a
direction set to the value
of the direction parameter, false as iterable flag value, and undefined
key and value.
The source
of the cursor is the IDBIndexSync this function was called on.
If the range parameter is a key range then the cursor's range is set to that range. Otherwise, if the range parameter is a valid key then the cursor's range is set to key range containing only that key value. If the range parameter is not specified, the cursor's key range is left as undefined.
This method runs the steps for synchronously executing
a request and returns the result, in this case a cursor object. The steps are run with this
IDBIndexSync as source and the steps for iterating a cursor as operation,
using the created cursor as cursor and with undefined as key
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| range | |
✘ | ✔ | The key range to use as the cursor's range |
| direction | unsigned short |
✘ | ✔ | The cursor's required direction |
| Exception | Description | ||||
|---|---|---|---|---|---|
IDBDatabaseException |
|
IDBCursorSyncUsing the synchronous API, an application can process all the records in the cursor's range.
By default, a cursor walks over objects starting at the first record and ending at the last record including all the duplicates encountered along the way.
var tx = db.transaction('Contact');
var store = tx.objectStore('Contact');
var cursor = store.openCursor();
while(cursor.continue()) {
var value = cursor.value;
// act on each object or key
}
To start at the last record and end in the first record, the cursor
should be created with the direction parameter PREV.
var cursor = store.openCursor(IDBCursorSync.PREV);
while(cursor.continue()) {
// act on each object or key
}
To start at a certain key and end in the last record, i.e., for a lower-bounded cursor, while skipping duplicates, the cursor should be created with both the required start key and the direction parameter.
var range = IDBKeyRange.leftBound(key);
var cursor = store.openCursor(range, IDBCursorSync.NEXT_NO_DUPLICATE);
It is also possible to create a bounded cursor, i.e., with
application-specified starting and ending points, the
cursor should be created with both the required keys.
If the range is inclusive of both keys, then additional
flags are required. In the following example, all keys
with values in the inclusive range (start,
end) are returned with all their duplicates,
from the beginning of the range to its end.
var range = IDBKeyRange.bound(start, end);
var cursor = objects.openCursor(range);
interface IDBCursorSync {
const unsigned short NEXT = 0;
const unsigned short NEXT_NO_DUPLICATE = 1;
const unsigned short PREV = 2;
const unsigned short PREV_NO_DUPLICATE = 3;
readonly attribute Object source;
readonly attribute unsigned short direction;
readonly attribute any key;
IDBRequest update (in any value) raises (IDBDatabaseException, DOMException);
void advance (in int count);
boolean continue (in optional any key) raises (IDBDatabaseException);
void delete () raises (IDBDatabaseException);
};
direction of type unsigned short, readonlykey of type any, readonlyundefined. I.e. if it's currently being iterated or has
iterated past the end of its range.source of type Object, readonlyIDBObjectStoreSync or IDBIndexSync
which this cursor is iterating. This function never returns null or throws an exception, even if the is currently being iterated, has iterated past its end,
or its transaction is not active.
advanceThis method runs the steps for synchronously executing a request. The steps are run with the cursor's source as source. The operation runs the steps for iterating a cursor count number of times with null as key and this cursor as cursor.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| count | int |
✘ | ✘ | The number of advances forward the cursor should make. |
voidcontinueIf this cursor's got value flag is false, this method throws a NOT_ALLOWED_ERR. If the key parameter is specified and fulfills any of these conditions this method must throw a DATA_ERR exception:
Otherwise this method runs the steps for synchronously executing a request. The steps are run with the cursor's source as source and the steps for iterating a cursor as operation, using the cursor this is called on as cursor and the key parameter as key.
Before this method returns, unless an exception was thrown, it sets the got value flag in the cursor to false.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| key | any |
✘ | ✔ | The next key to position this cursor at |
| Exception | Description | ||||||
|---|---|---|---|---|---|---|---|
IDBDatabaseException |
|
booleandelete
This method throws a READ_ONLY_ERR if the transaction which this IDBCursorSync belongs to
has its mode set to READ_ONLY. If this cursor's got value flag is false,
or if this cursor was created using
openKeyCursor a
NOT_ALLOWED_ERR is thrown.
Otherwise this method runs the steps for synchronously executing a request. The steps are run
with this IDBCursorSync as source and the
steps for deleting a record from an
object store as operation, using this cursor's effective object store and
effective key as store and key respectively.
This method used to set this cursor's value to null. Do we want to
keep that?
| Exception | Description | ||||||
|---|---|---|---|---|---|---|---|
IDBDatabaseException |
|
voidupdate
This method throws a READ_ONLY_ERR if the transaction which this IDBCursorSync belongs to
has its mode set to READ_ONLY. If this cursor's got value flag is false or if this
cursor was created using openKeyCursor.
This method throws a NOT_ALLOWED_ERR. If the effective object store of this cursor uses in-line
keys and evaluating the
key path
of the value parameter results in a different value than the cursor's effective key,
this method throws DATA_ERR.
Otherwise this method creates a structured clone of the value parameter. If this throws an exception that exception is rethrown. It then runs the steps for synchronously executing a request and returns the result returned by these steps. The steps are run with this IDBCursorSync as source and the steps for storing a record into an object store as operation, using this cursor's effective object store as store, the created clone as value, this cursor's effective key as key, and with the no-overwrite flag flag set to false.
A result of running the steps for storing a record into an object store is that if the record has been deleted since the cursor moved to it, a new record will be created.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| value | any |
✘ | ✘ | The new value to store at the current position. |
| Exception | Description | ||||||||
|---|---|---|---|---|---|---|---|---|---|
IDBDatabaseException |
|
||||||||
| DOMException |
|
IDBRequestNEXT of type unsigned shortNEXT_NO_DUPLICATE of type unsigned shortPREV of type unsigned shortPREV_NO_DUPLICATE of type unsigned shortinterface IDBCursorWithValueSync : IDBCursorSync {
attribute any value;
};
value of type anyundefined. I.e. if it's currently being iterated or has
iterated past the end of its range. Note that if this property returns an object, it returns the same
object instance every time it is inspected, until the cursor is iterated. This means that if the object is modified,
those modifications will be seen by anyone inspecting the value of the cursor. However modifying such an object
does not modify the contents of the database.
When an application creates a transaction synchronously, it blocks until the user agent is able to reserve the required database objects.
interface IDBTransactionSync {
const unsigned short READ_ONLY = 0;
const unsigned short READ_WRITE = 1;
const unsigned short VERSION_CHANGE = 2;
readonly attribute unsigned short mode;
attribute IDBDatabaseSync db;
IDBObjectStoreSync objectStore (in DOMString name) raises (IDBDatabaseException);
void abort () raises (IDBDatabaseException);
};
db of type IDBDatabaseSyncmode of type unsigned short, readonlyabort| Exception | Description | ||
|---|---|---|---|
IDBDatabaseException |
|
voidobjectStoreIDBObjectStoreSync representing a object store
that is part of the to the scope of this transaction. Every call to this function on the same
IDBTransactionSync instance and with the same name returns the same
IDBObjectStoreSync instance.
However the retured IDBObjectStoreSync instance is specific to this
IDBTransactionSync.
If this function is called on a different IDBTransactionSync,
a different IDBObjectStoreSync instance is returned.
| Parameter | Type | Nullable | Optional | Description |
|---|---|---|---|---|
| name | DOMString |
✘ | ✘ | The requested object store |
| Exception | Description | ||
|---|---|---|---|
IDBDatabaseException |
|
IDBObjectStoreSyncREAD_ONLY of type unsigned shortREAD_WRITE of type unsigned shortVERSION_CHANGE of type unsigned shortsetVersion() method of
IDBDatabaseSync.Once a transaction is aborted or committed, the active transaction on this database connection is removed. A new transaction can be created to perform operations atomically.
The steps for opening a database are as follows. The algorithm in these steps take two arguments. A origin which requested the database to be opened, a database name. It also optionally takes a request which represents a request used when opening the database is done using an asynchronous API.
There can potentially be several connections waiting for a VERSION_CHANGE transaction to finish. Once that transaction finishes another connection could be created and a new VERSION_CHANGE transaction could be started before these steps has a chance to continue. In that case the implementation must keep waiting at this step. Similarly, at any point while waiting for VERSION_CHANTE transactions to finish, the delete pending flag could be set. In that case the implementation must keep waiting at this step until db has been deleted.
When the user agent is to create a transaction it must run the following steps. This algorithm takes five parameters: A connection, a mode, a list of storeNames of object stores to be included in the scope of the transaction, a timeout for the transaction starting, and a callbacks parameter for synchronously created transactions.
This should be specified more precisely. Maybe with some sort of global variable locked?
DOMStringList or Array leave it as is. Otherwise,
interpret it as an Array with one value, and that value is the stringified version of
storeNames. If any of the strings in storeNames identifies an object store which doesn't
exist, throw a NOT_FOUND_ERR exception.
Because the asynchronous API always passes in a timeout of infinite, only the synchronous API will ever time out.
When taking the steps for committing a transaction the implementation must execute the following algorithm. This algorithm takes one parameter, the transaction to commit.
Event interface and have its type set to "commit".
The event does not bubble and is not cancelable. The
propagation path for the event is transaction's
connection and
then transaction.
When taking the steps for aborting a transaction the implementation must execute the following algorithm. This algorithm takes two parameter, the transaction to abort and a code.
Event interface and have its type set to "abort".
The event does bubble but is not cancelable. The
propagation path for the event is transaction's
connection and
then transaction.
When taking the steps for asynchronously executing a request the implementation must run the following algorithm. The algorithm takes a source object and a operation to perform on a database.
These steps can be aborted at any point if the transaction the created request belongs to is aborted using the steps for aborting a transaction
IDBRequest object and set request to this object. Set request's
source to source and add request to the end of the
list of requests in transaction. Return
this object and run the remaining steps in this algorithm asynchronously.
Cursors override this step to reuse an existing IDBRequest. However they still put the
IDBRequest at the end of the list of requests in transaction.
undefined and set errorCode of the request
to the code of the error from operation. Finally fire an error event at request.
When taking the steps for synchronously executing a request the implementation must run the following algorithm. The algorithm takes a source object and a operation to perform on a database.
When taking the steps for extracting a key from a value using a key path, the implementation must run the following algorithm. The algorithm takes a key path named keyPath and a value named value and in some cases returns a key which may or may not be a valid key.
The steps for running a VERSION_CHANGE transaction are
as follows. This algorithm takes two parameters - a connection object which is used
to update the database and a new version number to be set for the database.
IDBVersionChangeRequest interface, return it, and
run the remaining steps in this algorithm asynchronously.
IDBDatabase and
IDBDatabaseSync
objects, except connection, connected to the same database as connection.
Fire a versionchange event at each object in openDatabases that is open. The event must not
be fired on objects which has the closePending flag set. The event must use the
IDBVersionChangeEvent interface and have the
version property set to version number.
This event must not bubble or be cancelable. The propagation path for the event is just the
IDBDatabase object itself.
Firing this event might cause one or more of the other objects in openDatabases to be closed, in which case
the versionchange event must not be fired at those objects if that hasn't yet been done.
If running asynchronously and any of the connections in openDatabases are still not closed, fire a
blocked event at request. The event must use the
IDBVersionChangeEvent interface
and have the version property set to version number.
This event must not bubble or be cancelable. The propagation path for the event is just request.
closePending flag set to true.
If .close() is called immediately but a transaction associated with the connection
keeps running for a "long time", should we also fire a blocked event?
closePending flag set to true,
abort the transaction by following the steps for aborting a transaction and abort this algorithm without taking
any further steps.
transaction, and so if the transaction is aborted, this change is reverted.
success event targeted at the request object. The result
propety of the event should be set to a new IDBTransaction object representing the
VERSION_CHANGE transaction created in step 4. If running synchronously, return the
IDBTransactionSync
created in step 4 to the caller.
transaction and let the
transaction
finish normally.
The steps for closing a database connection are as follows. These steps take one argument, a connection object.
closePending flag of connection to true.
Once the closePending flag has ben set to true no new transactions can be
created using connection. All functions that
create transactions first check the the
closePending flag first and
throw an exception if it is true.
Once the connection is closed, this can unblock the
steps for running a VERSION_CHANGE
transaction, and the steps for deleting a database, which both
wait for connections to a given database to be closed
before continuing.
The steps for deleting a database are as follows. The algorithm in these steps take three arguments. A origin which requested the database to be deleted, a database name. It also optionally takes a request which represents a request used when deleting the database is done using an asynchronous API.
IDBDatabase and
IDBDatabaseSync
objects connected to db.
Fire a versionchange event at each object in openDatabases that is open. The event must not
be fired on objects which has the closePending flag set. The event must use the
IDBVersionChangeEvent interface and have the
version property set to null.
This event must not bubble or be cancelable.
Firing this event might cause one or more of the other objects in openDatabases to be closed, in which case
the versionchange event must not be fired at those objects if that hasn't yet been done.
If any of the connections in openDatabases are still not closed, and request was provided,
fire a blocked event at request. The event must use the
IDBVersionChangeEvent
interface and have the version property set to null.
This event must not bubble or be cancelable.
Should we allow blocked to be fired here too, if waiting takes "too long"?
To fire a success event at a request, the implementation must run the following steps:
Event interface and have its type set to "success".
The event does not bubble or be cancelable. The
propagation path for the event is transaction's
connection,
then transaction and finally request. However if transaction is null, then the
propagation path is simply request.
To fire a error event at a request, the implementation must run the following steps:
Event interface and have its type set to "error".
The event does bubble and is cancelable. The
propagation path for the event is transaction's
connection,
then transaction and finally request. The event's default action is to abort the
transaction by running steps for aborting a transaction. However if transaction
is null, then the propagation path is simply request, there is no
default action and
is not cancelable.
TODO: need to define more error handling here.
This section describes various operations done on the data in object stores and indexes in a database. These operations are run by the steps for asynchronously executing a request and the steps for synchronously executing a request.
The steps for storing a record into an object store are as follows. The algorithm run by these steps takes four parameters: a object store store, a value, an optional key, and a no-overwrite flag.
long
or a float and this number is larger than, or equal to, the next key that store's
key generator would generate, change store's key generator such that the next
key it generates is the lowest integer larger than key.
CONSTRAINT_ERR
and abort this algorithm without taking any further steps.
Array, then set
index key to a newly created empty Array. For each item in
index's key path evaluate
the item on value. If this does not yield a value don't take any further actions for this index.
Otherwise add the value to the end of the index key Array.
Array,
and if index already contains a record with
key equal to index key,
and index has it's unique flag set to true, then set error code to CONSTRAINT_ERR and
abort this algorithm without taking any further steps.
Array,
and if index already contains a record with key
equal to any of the
values in index key, and index has it's unique flag set to true, then set error
code to CONSTRAINT_ERR and abort this algorithm without taking any further steps.
Array,
then store a record in index containig index key as its key and key as its
value. The record is stored in index's list of records such
that the list is sorted primarily on the records keys, and secondarily on the records values, in ascending
order.
Array,
then for each item in index key store a record in index containig
the items value as its key and key as its value. The records are stored in index's
list of records such that the list is sorted primarily on the records keys,
and secondarily on the records values, in ascending order.
Array to have length 0, in this case no records are added to
the index.
Array are themselves an Array, then the inner
Array is used as a key for that entry. In other words, Arrays are not recursively
"unpacked" to produce multiple rows. Only the outer-most Array is.
The steps for retrieving a value from an object store are as follows. These steps must be run with two parameters - the record key and the object store.
undefined.
The steps for retrieving a referenced value from an index are as follows. These steps must be run with two parameters - the record key and the index.
undefined.
The steps for retrieving a value from an index are as follows. These steps must be run with two parameters - the record key and the index.
undefined.
The steps for deleting a record from an object store are as follows. The algorithm run by these steps takes two parameters: a object store store and a key.
The steps for clearing an object store are as follows. The algorithm run by these steps takes one parameter: a object store store.
The steps for iterating a cursor are as follows. The algorithm run by these steps takes two parameters: a cursor and optional key to iterate to.
source is always a object store or a index.
records is always sorted in ascending key order. In the case of source being an index, records is secondarily sorted in ascending value order.
If direction is NEXT, let found record be the first record in records which satisfy all of the following requirements:
If direction is NEXT_NO_DUPLICATE, let found record be the first record in records which satisfy all of the following requirements:
If direction is PREV, let found record be the last record in records which satisfy all of the following requirements:
If direction is PREV_NO_DUPLICATE, let temp record be the last record in records which satisfy all of the following requirements:
If temp record is defined, let found record be the first record in records whose key is equal to temp record's key.
undefined. Abort these steps.
Set cursor's position to found record's key. If source is a index, set cursor's object store position to found record's value.
Set cursor's key to found record's key.
If cursor implements IDBCursorWithValue or
IDBCursorWithValueSync, then set
cursor's value to a
structured clone of found record
referenced value.
This should only be done right before firing the success event. Not asynchronously before. Not sure how/where to express that.
A third-party host (or any object capable of getting content distributed to multiple sites) could use a unique identifier stored in its client-side database to track a user across multiple sessions, building a profile of the user's activities. In conjunction with a site that is aware of the user's real id object (for example an e-commerce site that requires authenticated credentials), this could allow oppressive groups to target individuals with greater accuracy than in a world with purely anonymous Web usage.
There are a number of techniques that can be used to mitigate the risk of user tracking:
iframes.
User agents may automatically delete stored data after a period of time.
This can restrict the ability of a site to track a user, as the site would then only be able to track the user across multiple sessions when he authenticates with the site itself (e.g. by making a purchase or logging in to a service).
However, this also puts the user's data at risk.
User agents should present the database feature to the user in a way that associates them strongly with HTTP session cookies. [COOKIES]
This might encourage users to view such storage with healthy suspicion.
User agents may require the user to authorize access to databases before a site can use the feature.
User agents may record the origins of sites that contained content from third-party origins that caused data to be stored.
If this information is then used to present the view of data currently in persistent storage, it would allow the user to make informed decisions about which parts of the persistent storage to prune. Combined with a blacklist ("delete this data and prevent this domain from ever storing data again"), the user can restrict the use of persistent storage to sites that he trusts.
User agents may allow users to share their persistent storage domain blacklists.
This would allow communities to act together to protect their privacy.
While these suggestions prevent trivial use of this API for user tracking, they do not block it altogether. Within a single domain, a site can continue to track the user during a session, and can then pass all this information to the third party along with any identifying information (names, credit card numbers, addresses) obtained by the site. If a third party cooperates with multiple sites to obtain such information, a profile can still be created.
However, user tracking is to some extent possible even with no cooperation from the user agent whatsoever, for instance by using session identifiers in URLs, a technique already commonly used for innocuous purposes but easily repurposed for user tracking (even retroactively). This information can then be shared with other sites, using using visitors' IP addresses and other user-specific data (e.g. user-agent headers and configuration settings) to combine separate sessions into coherent user profiles.
User agents should treat persistently stored data as potentially sensitive; it's quite possible for e-mails, calendar appointments, health records, or other confidential documents to be stored in this mechanism.
To this end, user agents should ensure that when deleting data, it is promptly deleted from the underlying storage.