You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -107,13 +107,13 @@ IndexedDB uses the [standard serialization algorithm](https://www.w3.org/TR/html
107
107
108
108
An example of object that can't be stored: an object with circular references. Such objects are not serializable. `JSON.stringify` also fails for such objects.
109
109
110
-
**There must be an unique `key` for every value in the store.**
110
+
**There must be a unique `key` for every value in the store.**
111
111
112
112
A key must have a type one of: number, date, string, binary, or array. It's a unique object identifier: we can search/remove/update values by the key.
113
113
114
114
115
115
116
-
We can provide a key when we add an value to the store, similar to `localStorage`. That's good for storing primitive values. But when we store objects, IndexedDB allows to setup an object property as the key, that's much more convenient. Or we can auto-generate keys.
116
+
We can provide a key when we add a value to the store, similar to `localStorage`. That's good for storing primitive values. But when we store objects, IndexedDB allows to setup an object property as the key, that's much more convenient. Or we can auto-generate keys.
117
117
118
118
The syntax to create an object store:
119
119
```js
@@ -140,7 +140,7 @@ That's a technical limitation. Outside of the handler we'll be able to add/remov
140
140
141
141
To do an upgrade, there are two main ways:
142
142
1. We can compare versions and run per-version operations.
143
-
2. Or we can get a list of existing object stores as `db.objectStoreNames`. That object is a [DOMStringList](https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#domstringlist), and it provides `contains(name)` method to check for the existance. And then we can do updates depending on what exists.
143
+
2. Or we can get a list of existing object stores as `db.objectStoreNames`. That object is a [DOMStringList](https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#domstringlist), and it provides `contains(name)` method to check for the existence. And then we can do updates depending on what exists.
-`readwrite` -- can only read and write, but not modify object stores.
192
192
193
-
There'is also `versionchange` transaction type: such transactions can do everything, but we can't create them manually. IndexedDB automatically creates a `versionchange` transaction when opening the database, for `updateneeded` handler. That's why it's a single place where we can update the database structure, create/remove object stores.
193
+
There's also `versionchange` transaction type: such transactions can do everything, but we can't create them manually. IndexedDB automatically creates a `versionchange` transaction when opening the database, for `updateneeded` handler. That's why it's a single place where we can update the database structure, create/remove object stores.
194
194
195
195
```smart header="What are transaction types for?"
196
196
Performance is the reason why transactions need to be labeled either `readonly` and `readwrite`.
-**`keyPath`** -- path to the object field that the index should track (we're going to search by that field),
464
464
-**`option`** -- an optional object with properties:
465
465
-**`unique`** -- if true, then there may be only one object in the store with the given value at the `keyPath`. The index will enforce that by generating an error if we try to add a duplicate.
466
-
-**`multiEntry`** -- only used if there value on `keyPath` is an array. In that case, by default, the index will treat the whole array as the key. But if `multiEntry` is true, then the index will keep a list of store objects for each value in that array. So array members become index keys.
466
+
-**`multiEntry`** -- only used if the value on `keyPath` is an array. In that case, by default, the index will treat the whole array as the key. But if `multiEntry` is true, then the index will keep a list of store objects for each value in that array. So array members become index keys.
467
467
468
468
In our example, we store books keyed by `id`.
469
469
@@ -614,7 +614,7 @@ Whether there are more values matching the cursor or not -- `onsuccess` gets cal
614
614
615
615
In the example above the cursor was made for the object store.
616
616
617
-
But we also can make a cursor over an index. As we remember, indexes allow to search by an object field. Cursors over indexes to precisely the same as over object stores -- they save memory by returning one value at a timee.
617
+
But we also can make a cursor over an index. As we remember, indexes allow to search by an object field. Cursors over indexes to precisely the same as over object stores -- they save memory by returning one value at a time.
618
618
619
619
For cursors over indexes, `cursor.key` is the index key (e.g. price), and we should use `cursor.primaryKey` property the object key:
A we know already, a transaction auto-commits as soon as the browser is done with the current code and microtasks. So if we put an*macrotask* like `fetch` in the middle of a transaction, then the transaction won't wait for it to finish. It just auto-commits. So the next request in it fails.
691
+
As we already know, a transaction auto-commits as soon as the browser is done with the current code and microtasks. So if we put a*macrotask* like `fetch` in the middle of a transaction, then the transaction won't wait for it to finish. It just auto-commits. So the next request in it fails.
692
692
693
693
For a promise wrapper and `async/await` the situation is the same.
694
694
@@ -715,7 +715,7 @@ The workaround is same as when working with native IndexedDB: either make a new
715
715
716
716
Internally, the wrapper performs a native IndexedDB request, adding `onerror/onsuccess` to it, and returns a promise that rejects/resolves with the result.
717
717
718
-
That works most fine of the time. The examples are at the lib page <https://github.com/jakearchibald/idb>.
718
+
That works fine most of the time. The examples are at the lib page <https://github.com/jakearchibald/idb>.
719
719
720
720
In few rare cases, when we need the original `request` object, we can access it as `promise.request` property of the promise:
0 commit comments