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
Copy file name to clipboardExpand all lines: 6-data-storage/03-indexeddb/article.md
+22-18Lines changed: 22 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -131,9 +131,7 @@ In order to organize that, the `versionchange` event triggers on the "outdated"
131
131
132
132
If we don't listen for the `versionchange` event and don't close the old connection, then the second, new connection won't be made. The `openRequest` object will emit the `blocked` event instead of `success`. So the second tab won't work.
133
133
134
-
Here's the code to correctly handle the parallel upgrade.
135
-
136
-
It installs an `onversionchange` handler after the database is opened, that closes the old connection:
134
+
Here's the code to correctly handle the parallel upgrade. It installs the `onversionchange` handler, that triggers if the current database connection becomes outdated (db version is updated elsewhere) and closes the connection.
1. The `db.onversionchange` listener informs us about a parallel update attempt, if the current database version becomes outdated.
168
+
2. The `openRequest.onblocked` listener informs us about the opposite situation: there's a connection to an outdated version elsewhere, and it doesn't close, so the newer connection can't be made.
168
169
169
-
1. Add `db.onversionchange` listener after a successful opening, to be informed about a parallel update attempt.
170
-
2. Add `openRequest.onblocked` listener to handle the case when an old connection wasn't closed. This doesn't happen if we close it in `db.onversionchange`.
170
+
We can handle things more gracefully in `db.onversionchange`, prompt the visitor to save the data before the connection is closed and so on.
171
171
172
-
There are other variants. For example, we can take the time to close things gracefully in `db.onversionchange`, and prompt the visitor to save the data before the connection is closed. The new updating connection will be blocked immediately after `db.onversionchange` has finished without closing, and we can ask the visitor in the new tab to close other tabs for the update.
172
+
Or, an alternative approach would be to not close the database in `db.onversionchange`, but instead use the `onblocked` handler (in the new tab) to alert the visitor, tell him that the newer version can't be loaded until they close other tabs.
173
173
174
-
These update collisions happen rarely, but we should at least have some handling for them, e.g. `onblocked` handler, so that our script doesn't surprise the user by dying silently.
174
+
These update collisions happen rarely, but we should at least have some handling for them, at least `onblocked` handler, to prevent our script from dying silently.
There are two main types of search in an object store:
481
-
1. By a key or a key range. That is: by `book.id` in our "books" storage.
482
-
2. By another object field, e.g. `book.price`.
483
481
484
-
First let's deal with the first type of search: by a key.
482
+
1. By a key value or a key range. In our "books" storage that would be a value or range of values of `book.id`.
483
+
2. By another object field, e.g. `book.price`. This required an additional data structure, named "index".
484
+
485
+
### By key
485
486
486
-
Searching methods support both exact keys and so-called "ranges" -- [IDBKeyRange](https://www.w3.org/TR/IndexedDB/#keyrange) objects that specify an acceptable "key range".
487
+
First let's deal with the first type of search: by key.
487
488
488
-
Ranges are created using following calls:
489
+
Searching methods support both exact key values and so-called "ranges of values" -- [IDBKeyRange](https://www.w3.org/TR/IndexedDB/#keyrange) objects that specify an acceptable "key range".
490
+
491
+
`IDBKeyRange` objects are created using following calls:
489
492
490
493
-`IDBKeyRange.lowerBound(lower, [open])` means: `≥lower` (or `>lower` if `open` is true)
491
494
-`IDBKeyRange.upperBound(upper, [open])` means: `≤upper` (or `<upper` if `open` is true)
492
495
-`IDBKeyRange.bound(lower, upper, [lowerOpen], [upperOpen])` means: between `lower` and `upper`. If the open flags is true, the corresponding key is not included in the range.
493
496
-`IDBKeyRange.only(key)` -- a range that consists of only one `key`, rarely used.
494
497
495
-
Searching methods accept a `query` argument that can be either an exact key or a key range:
498
+
We'll see practical examples of using them very soon.
499
+
500
+
To perform the actual search, there are following methods. They accept a `query` argument that can be either an exact key or a key range:
496
501
497
502
-`store.get(query)` -- search for the first value by a key or a range.
498
503
-`store.getAll([query], [count])` -- search for all values, limit by `count` if given.
0 commit comments