This is a low level implementation of IndexedDB.
It is recommended you create an abstraction layer between your app and the IndexedDB.
Quick Start
Take a look at the demo app.
The easiest way to start is to drop the IDBDatabase block on your app.
You must implement the OnDBUpgradeNeeded event.
While this event is running you are inside a "special" transaction (IDBOpenDBRequest) and it is the only way to manipulate the structure of your database.
You can only use the methods IDBDatabase_ObjectStore_Create, IDBDatabase_ObjectStore_Delete, IDBObjectStore_Create_Index and IDBObjectStore_Delete_Index inside this event.
From this point on you always need to have a transaction to access the objects, even IDBObjectStore (similar to tables).
Transactions are done in 2 steps, first you specify the database, transaction type and what objects the transaction applies to. For this you use the IDBDatabase_Transaction method, which returns an IDBTransaction object.
Once you have a transaction you can then request an IDBObjectStore to manipulate.
So it is not uncommon to have dedicated methods to return an IDBObjectStore if you are manipulating a single object in a single transaction, eg.:
So a "fetch data" into a list for display with pagination would look something like this:
and fetching a single object:
Check the demo app for this example.
Public Resources
The IDBFactory interface of the IndexedDB API lets applications asynchronously access the indexed databases. The object that implements the interface is window.indexedDB. You open — that is, create and access — and delete a database with this object, and not directly with IDBFactory.
The IDBOpenDBRequest interface of the IndexedDB API provides access to the results of requests to open or delete databases (performed using IDBFactory.open and IDBFactory.deleteDatabase), using specific event handler attributes.
The IDBDatabase interface of the IndexedDB API provides a connection to a database; you can use an IDBDatabase object to open a transaction on your database then create, manipulate, and delete objects (data) in that database. The interface provides the only way to get and manage versions of the database.
The IDBTransaction interface of the IndexedDB API provides a static, asynchronous transaction on a database using event handler attributes. All reading and writing of data is done within transactions. You use IDBDatabase to start transactions, IDBTransaction to set the mode of the transaction (e.g. is it readonly or readwrite), and you access an IDBObjectStore to make a request. You can also use an IDBTransaction object to abort transactions.
The IDBObjectStore interface of the IndexedDB API represents an object store in a database. Records within an object store are sorted according to their keys. This sorting enables fast insertion, look-up, and ordered retrieval.
The IDBKeyRange interface of the IndexedDB API represents a continuous interval over some data type that is used for keys. Records can be retrieved from IDBObjectStore and IDBIndex objects using keys or a range of keys. You can limit the range using lower and upper bounds. For example, you can iterate over all values of a key in the value range A–Z. A key range can be a single value or a range with upper and lower bounds or endpoints. If the key range has both upper and lower bounds, then it is bounded; if it has no bounds, it is unbounded. A bounded key range can either be open (the endpoints are excluded) or closed (the endpoints are included).
IDBIndex interface of the IndexedDB API provides asynchronous access to an index in a database. An index is a kind of object store for looking up records in another object store, called the referenced object store. You use this interface to retrieve data. You can retrieve records in an object store through the primary key or by using an index. An index lets you look up records in an object store using properties of the values in the object stores records other than the primary key.
A Note about Cursors
The implementation of cursors in IndexedDB is dependent on the ability to fire an event every time the cursor advances.
This could be implemented via an event at the block level but it does feel unnatural.
For now and although cursor related methods exist on the above API's, the IDBCursor as not been implemented.