RetroSearch Browse

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://developer.cdn.mozilla.net/ru/docs/Web/API/IndexedDB_API/Using_IndexedDB below:

ÐÑÐ¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°Ð½Ð¸Ðµ IndexedDB

ÐÐ± ÑÑÐ¾Ð¼ Ð´Ð¾ÐºÑÐ¼ÐµÐ½ÑÐµ

Ð¢Ð¸Ð¿Ð¸ÑÐ½Ð°Ñ ÑÑÐµÐ¼Ð° ÑÐ°Ð±Ð¾ÑÑ Ñ Ð±Ð°Ð·Ð¾Ð¹

ÐÑÐºÑÑÑÑ Ð±Ð°Ð·Ñ Ð´Ð°Ð½Ð½ÑÑ.
Ð¡Ð¾Ð·Ð´Ð°ÑÑ ÑÑÐ°Ð½Ð¸Ð»Ð¸ÑÐµ Ð¾Ð±ÑÐµÐºÑÐ¾Ð² Ð² Ð±Ð°Ð·Ðµ Ð´Ð°Ð½Ð½ÑÑ, Ð½Ð°Ð´ ÐºÐ¾ÑÐ¾ÑÐ¾Ð¹ Ð±ÑÐ´ÑÑ Ð²ÑÐ¿Ð¾Ð»Ð½ÑÑÑÑÑ Ð½Ð°ÑÐ¸ Ð¾Ð¿ÐµÑÐ°ÑÐ¸Ð¸.
ÐÐ°Ð¿ÑÑÑÐ¸ÑÑ ÑÑÐ°Ð½Ð·Ð°ÐºÑÐ¸Ñ Ð¸ Ð²ÑÐ´Ð°ÑÑ Ð·Ð°Ð¿ÑÐ¾Ñ Ð½Ð° Ð²ÑÐ¿Ð¾Ð»Ð½ÐµÐ½Ð¸Ðµ ÐºÐ°ÐºÐ¾Ð¹-Ð»Ð¸Ð±Ð¾ Ð¾Ð¿ÐµÑÐ°ÑÐ¸Ð¸ Ñ Ð±Ð°Ð·Ð¾Ð¹ Ð´Ð°Ð½Ð½ÑÑ, Ð½Ð°Ð¿ÑÐ¸Ð¼ÐµÑ, Ð´Ð¾Ð±Ð°Ð²Ð»ÐµÐ½Ð¸Ðµ Ð¸Ð»Ð¸ Ð¸Ð·Ð²Ð»ÐµÑÐµÐ½Ð¸Ðµ Ð´Ð°Ð½Ð½ÑÑ.
ÐÐ´Ð°ÑÑ Ð·Ð°Ð²ÐµÑÑÐµÐ½Ð¸Ñ Ð¾Ð¿ÐµÑÐ°ÑÐ¸Ð¸, Ð¾Ð±ÑÐ°Ð±Ð°ÑÑÐ²Ð°Ñ ÑÐ¾Ð±ÑÑÐ¸Ðµ DOM, Ð½Ð° ÐºÐ¾ÑÐ¾ÑÐ¾Ðµ Ð´Ð¾Ð»Ð¶ÐµÐ½ Ð±ÑÑÑ ÑÑÑÐ°Ð½Ð¾Ð²Ð»ÐµÐ½ Ð½Ð°Ñ Ð¾Ð±ÑÐ°Ð±Ð¾ÑÑÐ¸Ðº.
Ð¡Ð´ÐµÐ»Ð°ÑÑ ÑÑÐ¾-ÑÐ¾ Ñ ÑÐµÐ·ÑÐ»ÑÑÐ°ÑÐ°Ð¼Ð¸ (ÐºÐ¾ÑÐ¾ÑÑÐµ Ð¼Ð¾Ð³ÑÑ Ð±ÑÑÑ Ð½Ð°Ð¹Ð´ÐµÐ½Ñ Ð² Ð²Ð¾Ð·Ð²ÑÐ°ÑÐ°ÐµÐ¼Ð¾Ð¼ Ð¿Ð¾ Ð½Ð°ÑÐµÐ¼Ñ Ð·Ð°Ð¿ÑÐ¾ÑÑ Ð¾Ð±ÑÐµÐºÑÐµ ).

// Ð¿ÑÐ¾Ð²ÐµÑÑÐµÐ¼ ÑÑÑÐµÑÑÐ²Ð¾Ð²Ð°Ð½Ð¸Ñ Ð¿ÑÐµÑÐ¸ÐºÑÐ°.
window.indexedDB =
  window.indexedDB ||
  window.mozIndexedDB ||
  window.webkitIndexedDB ||
  window.msIndexedDB;
// ÐÐ ÐÐ¡ÐÐÐÐ¬ÐÐ£ÐÐ¢Ð "var indexedDB = ..." Ð²Ð½Ðµ ÑÑÐ½ÐºÑÐ¸Ð¸.
// ÑÐ°ÐºÐ¶Ðµ Ð¼Ð¾Ð³ÑÑ Ð¾ÑÐ»Ð¸ÑÐ°ÑÑÑÑ Ð¸ window.IDB* objects: Transaction, KeyRange Ð¸ ÑÐ´
window.IDBTransaction =
  window.IDBTransaction ||
  window.webkitIDBTransaction ||
  window.msIDBTransaction;
window.IDBKeyRange =
  window.IDBKeyRange || window.webkitIDBKeyRange || window.msIDBKeyRange;
// (Mozilla Ð½Ð¸ÐºÐ¾Ð³Ð´Ð° Ð½Ðµ ÑÐ¾Ð·Ð´Ð°Ð²Ð°Ð»Ð° Ð¿ÑÐµÑÐ¸ÐºÑÐ¾Ð² Ð´Ð»Ñ Ð¾Ð±ÑÐµÐºÑÐ¾Ð², Ð¿Ð¾ÑÑÐ¾Ð¼Ñ window.mozIDB* Ð½Ðµ ÑÑÐµÐ±ÑÐµÑÑÑ Ð¿ÑÐ¾Ð²ÐµÑÑÑÑ)

if (!window.indexedDB) {
  window.alert(
    "ÐÐ°Ñ Ð±ÑÐ°ÑÐ·ÐµÑ Ð½Ðµ Ð¿Ð¾Ð´Ð´ÐµÑÐ¶Ð¸Ð²Ð°ÐµÑ ÑÑÐ°Ð±Ð¸Ð»ÑÐ½ÑÑ Ð²ÐµÑÑÐ¸Ñ IndexedDB. Ð¢Ð°ÐºÐ¸Ðµ-ÑÐ¾ ÑÑÐ½ÐºÑÐ¸Ð¸ Ð±ÑÐ´ÑÑ Ð½ÐµÐ´Ð¾ÑÑÑÐ¿Ð½Ñ",
  );
}

ÐÑÐºÑÑÑÐ¸Ðµ Ð±Ð°Ð·Ñ Ð´Ð°Ð½Ð½ÑÑ

ÐÐ°Ðº-ÑÐ¾ ÑÐ°Ðº:

// ÐÑÐºÑÑÐ²Ð°ÐµÐ¼ Ð±Ð°Ð·Ñ Ð´Ð°Ð½Ð½ÑÑ MyTestDatabase
var request = window.indexedDB.open("MyTestDatabase", 3);

var request = indexedDB.open("MyTestDatabase", 2.4); // Ð½Ðµ Ð´ÐµÐ»Ð°Ð¹ÑÐµ ÑÐ°Ðº, Ð¿Ð¾ÑÐ¾Ð¼Ñ ÑÑÐ¾ Ð²ÐµÑÑÐ¸Ñ Ð±ÑÐ´ÐµÑ Ð¾ÐºÑÑÐ³Ð»ÐµÐ½Ð° Ð´Ð¾ 2

Ð£ÑÑÐ°Ð½Ð¾Ð²ÐºÐ° Ð¾Ð±ÑÐ°Ð±Ð¾ÑÑÐ¸ÐºÐ¾Ð²

request.onerror = function (event) {
  // Ð¡Ð´ÐµÐ»Ð°ÑÑ ÑÑÐ¾-ÑÐ¾ Ð¿ÑÐ¸ Ð¾ÑÐ¸Ð±ÐºÐµ request.errorCode!
};
request.onsuccess = function (event) {
  // ÐÑÐ¿Ð¾Ð»Ð½Ð¸ÑÑ ÐºÐ°ÐºÐ¾Ð¹-ÑÐ¾ ÐºÐ¾Ð´ ÐµÑÐ»Ð¸ Ð·Ð°Ð¿ÑÐ¾Ñ ÑÑÐ¿ÐµÑÐ½ÑÐ¹ request.result!
};

var db;
var request = indexedDB.open("MyTestDatabase");
request.onerror = function (event) {
  alert(
    "ÐÐ¾ÑÐµÐ¼Ñ Ð²Ñ Ð½Ðµ Ð¿Ð¾Ð·Ð²Ð¾Ð»ÑÐµÑÐµ Ð¼Ð¾ÐµÐ¼Ñ Ð²ÐµÐ±-Ð¿ÑÐ¸Ð»Ð¾Ð¶ÐµÐ½Ð¸Ñ Ð¸ÑÐ¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÑ IndexedDB?!",
  );
};
request.onsuccess = function (event) {
  db = event.target.result;
};

ÐÐ±ÑÐ°Ð±Ð¾ÑÐºÐ° Ð¾ÑÐ¸Ð±Ð¾Ðº

db.onerror = function (event) {
  // Ð²ÑÐµ Ð¾ÑÐ¸Ð±ÐºÐ¸ Ð²ÑÐ²Ð¾Ð´Ð¸Ð¼ Ð² alert
  alert("Database error: " + event.target.errorCode);
};

// ÐÑÐ¾ ÑÐ¾Ð±ÑÑÐ¸Ðµ Ð¿Ð¾ÑÐ²Ð¸Ð»Ð¾ÑÑ ÑÐ¾Ð»ÑÐºÐ¾ Ð² ÑÐ°Ð¼ÑÑ Ð½Ð¾Ð²ÑÑ Ð±ÑÐ°ÑÐ·ÐµÑÐ°Ñ
request.onupgradeneeded = function (event) {
  var db = event.target.result;

  // Ð¡Ð¾Ð·Ð´Ð°ÑÐ¼ ÑÑÐ°Ð½Ð¸Ð»Ð¸ÑÐµ Ð¾Ð±ÑÐµÐºÑÐ¾Ð² Ð´Ð»Ñ ÑÑÐ¾Ð¹ Ð±Ð°Ð·Ñ Ð´Ð°Ð½Ð½ÑÑ
  var objectStore = db.createObjectStore("name", { keyPath: "myKey" });
};

var request = indexedDB.open("MyTestDatabase", 2.4); // ÐÑÐ´ÐµÑ Ð¾ÐºÑÑÐ³Ð»ÐµÐ½Ð¾ Ð´Ð¾ 2

Ð¡ÑÑÑÐºÑÑÑÐ° Ð±Ð°Ð·Ñ Ð´Ð°Ð½Ð½ÑÑ

Now to structure the database. IndexedDB uses object stores rather than tables, and a single database can contain any number of object stores. Whenever a value is stored in an object store, it is associated with a key. There are several different ways that a key can be supplied depending on whether the object store uses a key path or a key generator.

The following table shows the different ways the keys are supplied.

Key Path Key Generator Description No No This object store can hold any kind of value, even primitive values like numbers and strings. You must supply a separate key argument whenever you want to add a new value. Yes No This object store can only hold JavaScript objects. The objects must have a property with the same name as the key path. No Yes This object store can hold any kind of value. The key is generated for you automatically, or you can supply a separate key argument if you want to use a specific key. Yes Yes This object store can only hold JavaScript objects. Usually a key is generated and the value of the generated key is stored in the object in a property with the same name as the key path. However, if such a property already exists, the value of that property is used as key rather than generating a new key.

You can also create indices on any object store, provided the object store holds objects, not primitives. An index lets you look up the values stored in an object store using the value of a property of the stored object, rather than the object's key.

Additionally, indexes have the ability to enforce simple constraints on the stored data. By setting the unique flag when creating the index, the index ensures that no two objects are stored with both having the same value for the index's key path. So, for example, if you have an object store which holds a set of people, and you want to ensure that no two people have the same email address, you can use an index with the unique flag set to enforce this.

That may sound confusing, but this simple example should illustrate the concepts:

// This is what our customer data looks like.
const customerData = [
  { ssn: "444-44-4444", name: "Bill", age: 35, email: "bill@company.com" },
  { ssn: "555-55-5555", name: "Donna", age: 32, email: "donna@home.org" },
];
const dbName = "the_name";

var request = indexedDB.open(dbName, 2);

request.onerror = function (event) {
  // Handle errors.
};
request.onupgradeneeded = function (event) {
  var db = event.target.result;

  // Create an objectStore to hold information about our customers. We're
  // going to use "ssn" as our key path because it's guaranteed to be
  // unique.
  var objectStore = db.createObjectStore("customers", { keyPath: "ssn" });

  // Create an index to search customers by name. We may have duplicates
  // so we can't use a unique index.
  objectStore.createIndex("name", "name", { unique: false });

  // Create an index to search customers by email. We want to ensure that
  // no two customers have the same email, so use a unique index.
  objectStore.createIndex("email", "email", { unique: true });

  // Store values in the newly created objectStore.
  for (var i in customerData) {
    objectStore.add(customerData[i]);
  }
};

As mentioned previously, onupgradeneeded is the only place where you can alter the structure of the database. In it, you can create and delete object stores and build and remove indices.

Object stores are created with a single call to createObjectStore(). The method takes a name of the store, and a parameter object. Even though the parameter object is optional, it is very important, because it lets you define important optional properties and refine the type of object store you want to create. In our case, we've asked for an object store named "customers" and defined a keyPath that is the property that makes an individual object in the store unique. That property in this example is "ssn" since a social security number is guaranteed to be unique. "ssn" must be present on every object that is stored in the objectStore.

We've also asked for an index named "name" that looks at the name property of the stored objects. As with createObjectStore(), createIndex() takes an optional options object that refines the type of index that you want to create. Adding objects that don't have a name property still succeeds, but the object won't appear in the "name" index.

We can now retrieve the stored customer objects using their ssn from the object store directly, or using their name by using the index. To learn how this is done, see the section on using an index.

Adding and removing data

Before you can do anything with your new database, you need to start a transaction. Transactions come from the database object, and you have to specify which object stores you want the transaction to span. Also, you need to decide if you're going to make changes to the database or if you just need to read from it. Although transactions have three modes (read-only, read/write, and versionchange), you're better off using a read-only transaction when you can, because they can run concurrently

Adding data to the database

If you've just created a database, then you probably want to write to it. Here's what that looks like:

var transaction = db.transaction(["customers"], "readwrite");
// Note: Older experimental implementations use the deprecated constant IDBTransaction.READ_WRITE instead of "readwrite".
// In case you want to support such an implementation, you can just write:
// var transaction = db.transaction(["customers"], IDBTransaction.READ_WRITE);

The transaction() function takes two arguments (though one is optional) and returns a transaction object. The first argument is a list of object stores that the transaction will span. You can pass an empty array if you want the transaction to span all object stores, but don't do it because the spec says an empty array should generate an InvalidAccessError. If you don't specify anything for the second argument, you get a read-only transaction. Since you want to write to it here you need to pass the "readwrite" flag.

Now that you have a transaction you need to understand its lifetime. Transactions are tied very closely to the event loop. If you make a transaction and return to the event loop without using it then the transaction will become inactive. The only way to keep the transaction active is to make a request on it. When the request is finished you'll get a DOM event and, assuming that the request succeeded, you'll have another opportunity to extend the transaction during that callback. If you return to the event loop without extending the transaction then it will become inactive, and so on. As long as there are pending requests the transaction remains active. Transaction lifetimes are really very simple but it might take a little time to get used to. A few more examples will help, too. If you start seeing TRANSACTION_INACTIVE_ERR error codes then you've messed something up.

Transactions can receive DOM events of three different types: error, abort, and complete. We've talked about the way that error events bubble, so a transaction receives error events from any requests that are generated from it. A more subtle point here is that the default behavior of an error is to abort the transaction in which it occurred. Unless you handle the error by calling preventDefault() on the error event, the entire transaction is rolled back. This design forces you to think about and handle errors, but you can always add a catchall error handler to the database if fine grained error handling is too cumbersome. If you don't handle an error event or if you call abort() on the transaction, then the transaction is rolled back and an abort event is fired on the transaction. Otherwise, after all pending requests have completed, you'll get a complete event. If you're doing lots of database operations, then tracking the transaction rather than individual requests can certainly aide your sanity.

Now that you have a transaction, you'll need to get the object store from it. Transactions only let you have an object store that you specified when creating the transaction. Then you can add all the data you need.

// Do something when all the data is added to the database.
transaction.oncomplete = function (event) {
  alert("All done!");
};

transaction.onerror = function (event) {
  // Don't forget to handle errors!
};

var objectStore = transaction.objectStore("customers");
for (var i in customerData) {
  var request = objectStore.add(customerData[i]);
  request.onsuccess = function (event) {
    // event.target.result == customerData[i].ssn;
  };
}

The result of a request generated from a call to add() is the key of the value that was added. So in this case, it should equal the ssn property of the object that was added, since the object store uses the ssn property for the key path. Note that the add() function requires that no object already be in the database with the same key. If you're trying to modify an existing entry, or you don't care if one exists already, use the put() function.

Removing data from the database

Removing data is very similar:

var request = db
  .transaction(["customers"], "readwrite")
  .objectStore("customers")
  .delete("444-44-4444");
request.onsuccess = function (event) {
  // It's gone!
};

Getting data from the database

Now that the database has some info in it, you can retrieve it in several ways. First, the simple get(). You need to provide the key to retrieve the value, like so:

var transaction = db.transaction(["customers"]);
var objectStore = transaction.objectStore("customers");
var request = objectStore.get("444-44-4444");
request.onerror = function (event) {
  // Handle errors!
};
request.onsuccess = function (event) {
  // Do something with the request.result!
  alert("Name for SSN 444-44-4444 is " + request.result.name);
};

That's a lot of code for a "simple" retrieval. Here's how you can shorten it up a bit, assuming that you handle errors at the database level:

db
  .transaction("customers")
  .objectStore("customers")
  .get("444-44-4444").onsuccess = function (event) {
  alert("Name for SSN 444-44-4444 is " + event.target.result.name);
};

See how this works? Since there's only one object store, you can avoid passing a list of object stores you need in your transaction and just pass the name as a string. Also, you're only reading from the database, so you don't need a "readwrite" transaction. Calling transaction() with no mode specified gives you a "readonly" transaction. Another subtlety here is that you don't actually save the request object to a variable. Since the DOM event has the request as its target you can use the event to get to the result property. Easy, right?!

Using a cursor

Using get() requires that you know which key you want to retrieve. If you want to step through all the values in your object store, then you can use a cursor. Here's what it looks like:

var objectStore = db.transaction("customers").objectStore("customers");

objectStore.openCursor().onsuccess = function (event) {
  var cursor = event.target.result;
  if (cursor) {
    alert("Name for SSN " + cursor.key + " is " + cursor.value.name);
    cursor.continue();
  } else {
    alert("No more entries!");
  }
};

The openCursor() function takes several arguments. First, you can limit the range of items that are retrieved by using a key range object that we'll get to in a minute. Second, you can specify the direction that you want to iterate. In the above example, we're iterating over all objects in ascending order. The success callback for cursors is a little special. The cursor object itself is the result of the request (above we're using the shorthand, so it's event.target.result). Then the actual key and value can be found on the key and value properties of the cursor object. If you want to keep going, then you have to call continue() on the cursor. When you've reached the end of the data (or if there were no entries that matched your openCursor() request) you still get a success callback, but the result property is undefined.

One common pattern with cursors is to retrieve all objects in an object store and add them to an array, like this:

var customers = [];

objectStore.openCursor().onsuccess = function (event) {
  var cursor = event.target.result;
  if (cursor) {
    customers.push(cursor.value);
    cursor.continue();
  } else {
    alert("Got all customers: " + customers);
  }
};

ÐÑÐµÐ´ÑÐ¿ÑÐµÐ¶Ð´ÐµÐ½Ð¸Ðµ: The following function is not part of the IndexedDB standard!

Mozilla has also implemented getAll() to handle this case. It isn't part of the IndexedDB standard, so it may disappear in the future. We've included it because we think it's useful. The following code does precisely the same thing as above:

objectStore.getAll().onsuccess = function (event) {
  alert("Got all customers: " + event.target.result);
};

There is a performance cost associated with looking at the value property of a cursor, because the object is created lazily. When you use getAll(), Gecko must create all the objects at once. If you're just interested in looking at each of the keys, for instance, it is much more efficient to use a cursor than to use getAll(). If you're trying to get an array of all the objects in an object store, though, use getAll().

Using an index

Storing customer data using the SSN as a key is logical since the SSN uniquely identifies an individual. (Whether this is a good idea for privacy is a different question, outside the scope of this article.) If you need to look up a customer by name, however, you'll need to iterate over every SSN in the database until you find the right one. Searching in this fashion would be very slow, so instead you can use an index.

var index = objectStore.index("name");
index.get("Donna").onsuccess = function (event) {
  alert("Donna's SSN is " + event.target.result.ssn);
};

The "name" cursor isn't unique, so there could be more than one entry with the name set to "Donna". In that case you always get the one with the lowest key value.

If you need to access all the entries with a given name you can use a cursor. You can open two different types of cursors on indexes. A normal cursor maps the index property to the object in the object store. A key cursor maps the index property to the key used to store the object in the object store. The differences are illustrated here:

index.openCursor().onsuccess = function (event) {
  var cursor = event.target.result;
  if (cursor) {
    // cursor.key is a name, like "Bill", and cursor.value is the whole object.
    alert(
      "Name: " +
        cursor.key +
        ", SSN: " +
        cursor.value.ssn +
        ", email: " +
        cursor.value.email,
    );
    cursor.continue();
  }
};

index.openKeyCursor().onsuccess = function (event) {
  var cursor = event.target.result;
  if (cursor) {
    // cursor.key is a name, like "Bill", and cursor.value is the SSN.
    // No way to directly get the rest of the stored object.
    alert("Name: " + cursor.key + ", SSN: " + cursor.value);
    cursor.continue();
  }
};

Specifying the range and direction of cursors

If you would like to limit the range of values you see in a cursor, you can use a key range object and pass it as the first argument to openCursor() or openKeyCursor(). You can make a key range that only allows a single key, or one the has a lower or upper bound, or one that has both a lower and upper bound. The bound may be "closed" (i.e., the key range includes the given value) or "open" (i.e., the key range does not include the given value). Here's how it works:

// Only match "Donna"
var singleKeyRange = IDBKeyRange.only("Donna");

// Match anything past "Bill", including "Bill"
var lowerBoundKeyRange = IDBKeyRange.lowerBound("Bill");

// Match anything past "Bill", but don't include "Bill"
var lowerBoundOpenKeyRange = IDBKeyRange.lowerBound("Bill", true);

// Match anything up to, but not including, "Donna"
var upperBoundOpenKeyRange = IDBKeyRange.upperBound("Donna", true);

//Match anything between "Bill" and "Donna", but not including "Donna"
var boundKeyRange = IDBKeyRange.bound("Bill", "Donna", false, true);

index.openCursor(boundKeyRange).onsuccess = function (event) {
  var cursor = event.target.result;
  if (cursor) {
    // Do something with the matches.
    cursor.continue();
  }
};

Sometimes you may want to iterate in descending order rather than in ascending order (the default direction for all cursors). Switching direction is accomplished by passing prev to the openCursor() function:

objectStore.openCursor(null, IDBCursor.prev).onsuccess = function (event) {
  var cursor = event.target.result;
  if (cursor) {
    // Do something with the entries.
    cursor.continue();
  }
};

Since the "name" index isn't unique, there might be multiple entries where name is the same. Note that such a situation cannot occur with object stores since the key must always be unique. If you wish to filter out duplicates during cursor iteration over indexes, you can pass nextunique (or prevunique if you're going backwards) as the direction parameter. When nextunique or prevunique is used, the entry with the lowest key is always the one returned.

index.openKeyCursor(null, IDBCursor.nextunique).onsuccess = function (event) {
  var cursor = event.target.result;
  if (cursor) {
    // Do something with the entries.
    cursor.continue();
  }
};

Version changes while a web app is open in another tab

When your web app changes in such a way that a version change is required for your database, you need to consider what happens if the user has the old version of your app open in one tab and then loads the new version of your app in another. When you call open() with a greater version than the actual version of the database, all other open databases must explicitly acknowledge the request before you can start making changes to the database. Here's how it works:

var openReq = mozIndexedDB.open("MyTestDatabase", 2);

openReq.onblocked = function (event) {
  // If some other tab is loaded with the database, then it needs to be closed
  // before we can proceed.
  alert("Please close all other tabs with this site open!");
};

openReq.onupgradeneeded = function (event) {
  // All other databases have been closed. Set everything up.
  db.createObjectStore(/* ... */);
  useDatabase(db);
};

openReq.onsuccess = function (event) {
  var db = event.target.result;
  useDatabase(db);
  return;
};

function useDatabase(db) {
  // Make sure to add a handler to be notified if another page requests a version
  // change. We must close the database. This allows the other page to upgrade the database.
  // If you don't do this then the upgrade won't happen until the user close the tab.
  db.onversionchange = function (event) {
    db.close();
    alert("A new version of this page is ready. Please reload!");
  };

  // Do stuff with the database.
}

Security

IndexedDB uses the same-origin principle, which means that it ties the store to the origin of the site that creates it (typically, this is the site domain or subdomain), so it cannot be accessed by any other origin.

Third party window content (e.g. <iframe> content) cannot access IndexedDB if the browser is set to never accept third party cookies (see Firefox bug 1147821).

Warning About Browser Shutdown

When the browser shuts down (because the user chose the Quit or Exit option), the disk containing the database is removed unexpectedly, or permissions are lost to the database store, the following things happen:

Each transaction on every affected database (or all open databases, in the case of browser shutdown) is aborted with an AbortError. The effect is the same as if IDBTransaction.abort() is called on each transaction.
Once all of the transactions have completed, the database connection is closed.
Finally, the IDBDatabase object representing the database connection receives a close event. You can use the IDBDatabase.onclose event handler to listen for these events, so that you know when a database is unexpectedly closed.

The behavior described above is new, and is only available as of the following browser releases: Firefox 50, Google Chrome 31 (approximately).

Prior to these browser versions, the transactions are aborted silently, and no close event is fired, so there is no way to detect an unexpected database closure.

Since the user can exit the browser at any time, this means that you cannot rely upon any particular transaction to complete, and on older browsers, you don't even get told when they don't complete. There are several implications of this behavior.

First, you should take care to always leave your database in a consistent state at the end of every transaction. For example, suppose that you are using IndexedDB to store a list of items that you allow the user to edit. You save the list after the edit by clearing the object store and then writing out the new list. If you clear the object store in one transaction and write the new list in another transaction, there is a danger that the browser will close after the clear but before the write, leaving you with an empty database. To avoid this, you should combine the clear and the write into a single transaction.

Second, you should never tie database transactions to unload events. If the unload event is triggered by the browser closing, any transactions created in the unload event handler will never complete. An intuitive approach to maintaining some information across browser sessions is to read it from the database when the browser (or a particular page) is opened, update it as the user interacts with the browser, and then save it to the database when the browser (or page) closes. However, this will not work. The database transactions will be created in the unload event handler, but because they are asynchronous they will be aborted before they can execute.

In fact, there is no way to guarantee that IndexedDB transactions will complete, even with normal browser shutdown. See Firefox bug 870645. As a workaround for this normal shutdown notification, you might track your transactions and add a beforeunload event to warn the user if any transactions have not yet completed at the time of unloading.

At least with the addition of the abort notifications and IDBDatabase.onclose, you can know when this has happened.

localForage: A Polyfill providing a simple name:value syntax for client-side data storage, which uses IndexedDB in the background, but falls back to Web SQL (deprecated) and then localStorage in browsers that don't support IndexedDB.
Dexie.js: A wrapper for IndexedDB that allows much faster code development via nice, simple syntax.
JsStore: A simple and advanced IndexedDB wrapper having SQL like syntax.
MiniMongo: A client-side in-memory MongoDB backed by localstorage with server sync over http. MiniMongo is used by MeteorJS.
PouchDB: A client-side implementation of CouchDB in the browser using IndexedDB
IDB: A tiny library that mostly mirrors the IndexedDB API but with small usability improvements.
idb-keyval: A super-simple-small (~600B) promise-based keyval store implemented with IndexedDB
$mol_db: Tiny (~1.3kB) TypeScript facade with promise-based API and automatic migrations.
RxDB: A NoSQL client side database that can be used on top of IndexedDB. Supports indexes, compression and replication. Also adds cross tab functionality and observability to IndexedDB.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://developer.cdn.mozilla.net/ru/docs/Web/API/IndexedDB_API/Using_IndexedDB below:

ÐÑÐ¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°Ð½Ð¸Ðµ IndexedDB - ÐÐ½ÑÐµÑÑÐµÐ¹ÑÑ Ð²ÐµÐ± API

ÐÑÐ¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°Ð½Ð¸Ðµ IndexedDB - ÐÐ½ÑÐµÑÑÐµÐ¹ÑÑ Ð²ÐµÐ± API