Skip to content

Commit bbf60dd

Browse files
committed
minor fixes
1 parent 7ad529e commit bbf60dd

File tree

1 file changed

+22
-18
lines changed

1 file changed

+22
-18
lines changed

6-data-storage/03-indexeddb/article.md

+22-18
Original file line numberDiff line numberDiff line change
@@ -131,9 +131,7 @@ In order to organize that, the `versionchange` event triggers on the "outdated"
131131

132132
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.
133133

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.
137135

138136
```js
139137
let openRequest = indexedDB.open("store", 2);
@@ -164,14 +162,16 @@ openRequest.onblocked = function() {
164162
*/!*
165163
```
166164

167-
Here we do two things:
165+
...In other words, here we do two things:
166+
167+
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.
168169

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.
171171

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.
173173

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.
175175

176176
## Object store
177177

@@ -475,24 +475,29 @@ request.onerror = function(event) {
475475
};
476476
```
477477

478-
## Searching by keys
478+
## Searching
479479

480480
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`.
483481

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
485486

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.
487488

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:
489492

490493
- `IDBKeyRange.lowerBound(lower, [open])` means: `≥lower` (or `>lower` if `open` is true)
491494
- `IDBKeyRange.upperBound(upper, [open])` means: `≤upper` (or `<upper` if `open` is true)
492495
- `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.
493496
- `IDBKeyRange.only(key)` -- a range that consists of only one `key`, rarely used.
494497

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:
496501

497502
- `store.get(query)` -- search for the first value by a key or a range.
498503
- `store.getAll([query], [count])` -- search for all values, limit by `count` if given.
@@ -522,13 +527,12 @@ books.getAllKeys(IDBKeyRange.lowerBound('js', true))
522527
```
523528

524529
```smart header="Object store is always sorted"
525-
Object store sorts values by key internally.
530+
An object store sorts values by key internally.
526531
527532
So requests that return many values always return them in sorted by key order.
528533
```
529534

530-
531-
## Searching by any field with an index
535+
### By a field using an index
532536

533537
To search by other object fields, we need to create an additional data structure named "index".
534538

0 commit comments

Comments
 (0)