IndexedDB Basic Concepts (translation)

INDEXEDDB is a way for you to persist data in your browser. Whether the network is available or not, it allows you to create Web applications with powerful data query capabilities that can be networked or offline. IndexedDB is suitable for applications that store large amounts of data (such as the Register of DVD rental libraries) and applications that do not require a persistent network operation (e.g., mail clients, to-dos, comment boards)

About

This document discusses the core concepts and terminology of INDEXEDDB. Will show you the focus and explain the key concepts

Here are some useful tips:

To learn more about the Indexeddb terminology, refer to Definitionssection (definition section).

For a detailed example of how to use the Indexeddb API, refer to USINGINDEXEDDB (using INDEXEDDB)

To indexeddb the API Reference document, go back to the main page, refer to the INDEXEDDBAPI article and its sub-title section, which documents the Indexeddb object type. For more information on how browsers store data, refer to browser storage limits and eviction criteria (browser storage limits and recycling policies).

INDEXEDDB Overview

IndexedDB lets you store and retrieve objects using key (key) as an index. All of the changes you make to the database occur in transactions (things). Just like most other Web storage scenarios, IndexedDB follows Same-originpolicy (same-origin policy). As a result, you can access your own data in the same domain, but you cannot access data from other domains.

IndexedDB is an asynchronous (asynchronous) API that can be applied to most environments, including Webworkers, a strategy for executing JS scripts in the background. It also had a synchronous (synchronous) version of the page, which was applied to webworkers, but was removed because the vast web developer was not enthusiastic about it.

Indexeddb once had a rival, Websql, but the official group announced on November 18, 2010 that it was not supporting it. Although two databases are used to store front-end data, they have different implementation mechanisms, Websql is a relational database, and INDEXEDDB is an indexed database.

Key Concepts

If you are used to other types of databases, you may not be able to quickly adapt to INDEXEDDB Therefore, keep the following important concepts in mind:

The IndexedDB database Stores "key-value" pairs. A value can be an object of a complex structure, and the key can be a property of those objects. You can create indexes for quick queries based on the properties of these objects, or you can store detailed tables

(Cannot translate here, forgive me). The "key" can also be a binary object.

INDEXEDDB is based on the transactional database model. All of the operations you have done with indexeddb occur in a transactional environment. The IndexedDB API provides a range of objects such as indexes,tables,cursors, etc., but

Each object needs to be bound to a specific transaction. Therefore, you cannot execute instructions outside of a transaction or open a cursor. A transaction has a definite life cycle, so if you try to use it after the end of the transaction, an exception is thrown.

Also, transactions are automatically committed and cannot be submitted manually.

The transactional data model is useful when you consider the results of the following actions: The user opens an instance of the same web app on two different tabs. Without a transactional operation, two instances can be

Mutual interference with each other's modifications.

If you are unfamiliar with database transaction operations, please refer to Wikipedia article on transactions. There are also transaction in the "Definition" section.

The IndexedDB API is almost always asynchronous. These APIs do not pass the data directly to you through the return value; instead, you must provide a callback function. Instead of "storing" or "querying" a value into (from) the database (by synchronizing), you should request an action from the database, and when that is done, you will get a DOM event that allows you to determine whether the operation was successful or failed. This may sound a bit complicated, but there is a sound mechanism for dealing with them. This way of working is not different from XMLHttpRequest.

IndexedDB uses a lot of "requests." Requests are objects that are responsible for receiving DOM events that indicate success or failure information (mentioned earlier). They have onsuccess and onerror attributes, and you can

With the use of AddEventListener (), RemoveEventListener (). They also have Readystate,result, and the ErrorCode attribute is used to inform the status of the request. The result property is very magical because

It can represent many different things, depending on the way the request is requested (for example, it can be a idbcursor instance, or the key of the data record you just inserted).

INDEXEDDB uses DOM events to inform you when the results are valid. DOM events always have a "type" property value (in Indexeddb, it is usually success or error). DOM events also have a "target" attribute that indicates the target of the event. In most cases, the target property of an event is a Idbrequest object that acts as a result of a database operation. Success events do not bubble and they cannot be canceled. For error events, it is bubbling and can be canceled. This is important because error events must be canceled, regardless of the transaction they are running in, unless they are canceled.

IndexedDB is object-oriented. INDEXEDDB is not a relational database that uses table "tables" to represent rows and columns, an important fundamental difference.

Affect the way you design and create your app.

In a traditional relational data store, you will use a table to store the dataset, where rows store records, columns store field names. In Indexeddb, instead, you need to create an object store for a data type, with

Simply persist the JavaScript object for the object store. Each object store can have an indexed dataset that enables it to query and iterate through. If you are not yet familiar with the object-oriented database management system, refer to Wikipedia article on Objectdatabase.

INDEXEDDB does not use Structured Query Language (SQL). Instead, an index-based query is used that produces a cursor that lets you iterate through the result set. If you are not yet familiar with unstructured (NoSQL), refer to Wikipediaarticle on NoSQL.

INDEXEDDB adhere to the same-origin strategy. The source is the port number of the--domain, the Application layer protocol, and the URL of the target file that the script will execute. Each source has its own associated set of databases, and each database has a name that can represent the source in which it resides.

Security boundaries allow INDEXEDDB to block web apps from accessing different domains. For example, an application in http://www.example.com/app/can access ttp://www.example.com/dir/content because they are in the same domain but cannot access the http://www.example.com : 8080/dir/(different ports) because they are in a different domain.

Definitions

This section defines and explains the terminology used in the INDEXEDDB API

Database

An information warehouse that typically includes one or more object stores. Each database must contain the following content:

Name: Identifies a database in a particular source that remains constant for the lifetime of the database. The name can be any string, (including an empty string).

Current version: When a database is first created, (if not specifically specified) its version number is an integer 1. Each database can have only one version number at any given time.

Durable

For the Firefox browser, the INDEXEDDB is data-persistent, meaning that in a read-write transaction, Idbtransaction.oncomplete is the only trigger

The condition is to ensure that all data has been written to disk.

Since Firefox 40, INDEXEDDB transactions have eased the durable (data durability guarantee) for improved performance, as well as in other INDEXEDDB-supported browsers. In this case, the "complete" event is triggered when the operating system is told to write data, but the data is not actually written to the disk. In this way, the event trigger is certainly faster than before, however, there is a vulnerability where the entire transaction will be lost if the operating system crashes or the system loses power before the data is fully written to the disk. Because of this rare disaster, most users don't need to worry about this.

Object Store

Data is stored in the database based on this mechanism. The object store persists a "key-value pair" record. Records in the object store are sorted in ascending order by "key"

Each object store must have a name that is uniquely represented in the database. The object store can optionally have a "key" generator and a "key" path.

If the object store has a "key" path, use the inline "key"; otherwise, use the out-of-line "key"

For more documentation on the object store, refer to Idbobjectstoreor idbobjectstoresync.

Version

When the database is first created, the version number is integer 1. Each database can have only one version number at a time, and the same database cannot have more than one version number at a time.

The only way to change the version number is to open it with a higher version number. This will open a Versionchange transaction and trigger the Upgradeneeded event.

The only place to update the schema of the database is in the event handle.

Note: This definition describes the latest specifications, which are supported only in the latest browsers. Older versions of browsers supported by Idbdatabase.setversion ()

The method has been abolished.

Database connection

An operation created when the database is opened (connections), a given database can have multiple connections at the same time

Transaction

A collection of atomic operations for data access and data updates for the specified database. It describes how you should manipulate the data. In fact, any read and update data operations must be performed in the transaction.

Data link connection can have multiple active transactions at the same time, as long as "write" transactions do not overlap scope (scope). The scope defined when a transaction is created determines which object store the transaction can relate to, and

Keep (object store) stable over the lifetime of the transaction remaining. Therefore, if a data connection already has a "write" transaction, the scope of the transaction covers the Flyingmonkey object store, you can open the

Two transactions and the transaction has scopes covering the Unicorncentaur and Unicornpegasus object stores. For a read transaction type, you can have more than one, even a scope overlap.

The life cycle of a transaction should be short, and if a transaction takes too long, the browser can end it, freeing up the storage resources it occupies. You can abort the transaction to rollback the transaction's data changes to the database. And

You don't even have to wait for the transaction to open or activate to abort it.

INDEXEDDB three types of transaction modes: Readwrite,readonly, and Versionchange. Create and delete objects stores and indexes can only be used

Versionchange transactions. To learn more about the types of transactions, refer to the INDEXEDDB documentation.

It is very important that everything is happening in the transaction. If you need to learn more about transactions, especially how to associate versions, please refer to the

IDbTransaction, it also has a special documentation description. To learn about the Sync API, refer to Idbtransactionsync.

Request

An operation that is used to perform read-write behavior on the database. Each request represents a read or write.

Index is a dedicated object store that queries records stored in another object store, also known as the "Reference" object store. Index is a persistent "key-value" record collection in which the value of the record is indexed to the

Like the "key" in the store.

(For example: Object Store:objstore1; Store data: {name:nancy;age:28}.) Index:objstore2; Store data: {item1:name; item2:age})

When an indexed object has a new record inserted, updated, deleted, the records in index are automatically populated. Each record in index can point to only one indexed object

Records, but multiple records in index can point to the same record for the indexed object. When the indexed object changes, all relevant index records are automatically updated. Alternatively, you can (directly) use "key" in the

Query records like store. (the "key" here is the key-value pair in the store).

To learn more about how to use index, please refer to USINGINDEXEDDB. For the index document, please refer to Idbkeyrange.

Key and value

Key

A "key" is a data value that is used to organize and query stored records in the object store. The object store can get "keys" from the following three sources:

Key Generator key generator, key path KeyPath, or explicitly specify the value of "key". The "key" contains an integer value that is larger than the "key" (the value) in front of it.

Each record in the object store must contain a unique key, so you cannot have multiple records with the same "key".

The "key" can be one of the following types: string, date, float, a binary blob,andarray. For arrays, the value of "key" can be from empty to infinity,

And you can include another array in the array. Alternatively, you can use the Index object to query the record data in the object store.

Key generator

A mechanism for generating new "keys" in queue order. If the object store does not have a key generator, the application must provide a "key" for the records that are briefly deposited.

The generator cannot be shared between the object store. This is implemented inside the browser because you really can't create or access the key builder in web development

In-line Key

The in-row "key" is stored in the object store as part of the data record. It can be found through keypath. In-line "keys" can be created by the generator.

After the in-line "key" is created, you can store the value through key path, or you can (directly) use it as a "key"

Out-of-line Key

"Keys" independent of records in the object store

Key path

Specifies that the browser should extract the "key" from the object store or get the "key" from index. A valid key path should contain one of the following:

An empty string, a JavaScript identifier, multiple JavaScript identifiers with a period separator, or an array containing any of them. However, you cannot include spaces.

Each record has a value that can contain any content that can be expressed in JavaScript, such as boolean,number,string, date, object, array, regexp, undefined, and null. When an object or array is stored, its properties and values can be any valid value. Blobs and files types can be stored. Refer to specification.

Scopes and scopes

Scope

The target of the transaction application is the collection of object store and index. A read-only transaction can perform overlapping scopes at the same time. Instead, the scope of a write transaction cannot overlap. You can still open multiple active transactions at the same time, but they must be queued and executed sequentially.

Cursor

A mechanism that iterates through multiple records according to the scope of the "key". The cursor's "source" indicates which index or object store is being traversed. Cursors have a starting position within the range of "keys" and can be moved in ascending or descending order.

For more cursor knowledge, refer to Idbcursor or Idbcursorsync

The range of "keys"

A contiguous interval of the specified data type that applies to the key. You can query the record in the object store or index by using the range "key" or "key".

You can limit or filter the range of "keys" by applying the upper and lower limits. For example, you can iterate through all the results within the range of the key between "X, Y".

IndexedDB's design covers most scenarios where client storage is required. However, the following cases are exceptions:

International synchronizing. Not all language sorts apply the same way, so INDEXEDDB does not support internationalization ordering. Although the database does not support internationalization ordering, you can read the data out of the database and

International sorting issues. Note that localized auto-recognition sequencing has been attempted from Firefox 43 (Firefox only).

Synchronize synchronizing. The API is not designed to be synchronized with the server-side database. If you need this, you must design your own program.

Exact match query full text searching. The API does not support functions similar to the LIKE operator in SQL.

Also, be careful that the browser erases the entire database, such as the following:

The user requested the erase operation. Many browsers offer setting options that allow users to empty all records of a given website, including cookies, bookmarks, passwords and INDEXEDDB data.

The browser is in private mode. Some browsers have private mode (Firefox) or anonymous mode (Firefox), after the end of the session, the browser will delete the database data

The hard drive or quota (storage limit) has reached the limit.

Data error.

Incompatible settings change.

The browser's capabilities have changed, but manufacturers have struggled to keep the data in the browser (sorry. It's awkward here.)

IndexedDB Basic Concepts (translation)