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
Please note: as our current version is `2`, `onupgradeneeded` handler has a code branch for version `0`, suitable for users that are accessing for the first time and have no database, and also for version `1`, for upgrades.
98
+
Please note: as our current version is `2`, the `onupgradeneeded` handler has a code branch for version `0`, suitable for users that are accessing for the first time and have no database, and also for version `1`, for upgrades.
99
99
100
100
And then, only if `onupgradeneeded` handler finishes without errors, `openRequest.onsuccess` triggers, and the database is considered successfully opened.
// this event shouldn't trigger if we handle onversionchange correctly
158
158
159
-
// it means that there's another open connection to same database
159
+
// it means that there's another open connection to the same database
160
160
// and it wasn't closed after db.onversionchange triggered for it
161
161
};
162
162
*/!*
@@ -171,7 +171,7 @@ We can handle things more gracefully in `db.onversionchange`, prompt the visitor
171
171
172
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, at least `onblocked` handler, to prevent our script from dying silently.
174
+
These update collisions happen rarely, but we should at least have some handling for them, at least an `onblocked` handler, to prevent our script from dying silently.
175
175
176
176
## Object store
177
177
@@ -189,7 +189,7 @@ An example of an object that can't be stored: an object with circular references
189
189
190
190
**There must be a unique `key` for every value in the store.**
191
191
192
-
A key must be one of the these types - number, date, string, binary, or array. It's a unique identifier, so we can search/remove/update values by the key.
192
+
A key must be one of these types - number, date, string, binary, or array. It's a unique identifier, so we can search/remove/update values by the key.
193
193
194
194
195
195
@@ -253,7 +253,7 @@ db.deleteObjectStore('books')
253
253
254
254
The term "transaction" is generic, used in many kinds of databases.
255
255
256
-
A transaction is a group operations, that should either all succeed or all fail.
256
+
A transaction is a group of operations, that should either all succeed or all fail.
257
257
258
258
For instance, when a person buys something, we need to:
259
259
1. Subtract the money from their account.
@@ -347,9 +347,9 @@ Usually, we can assume that a transaction commits when all its requests are comp
347
347
348
348
So, in the example above no special call is needed to finish the transaction.
349
349
350
-
Transactions auto-commit principle has an important side effect. We can't insert an async operation like `fetch`, `setTimeout` in the middle of transaction. IndexedDB will not keep the transaction waiting till these are done.
350
+
Transactions auto-commit principle has an important side effect. We can't insert an async operation like `fetch`, `setTimeout` in the middle of a transaction. IndexedDB will not keep the transaction waiting till these are done.
351
351
352
-
In the code below, `request2` in line `(*)` fails, because the transaction is already committed, and can't make any request in it:
352
+
In the code below, `request2` in the line `(*)` fails, because the transaction is already committed, and can't make any request in it:
353
353
354
354
```js
355
355
let request1 =books.add(book);
@@ -370,7 +370,7 @@ That's because `fetch` is an asynchronous operation, a macrotask. Transactions a
370
370
371
371
Authors of IndexedDB spec believe that transactions should be short-lived. Mostly for performance reasons.
372
372
373
-
Notably, `readwrite` transactions "lock" the stores for writing. So if one part of application initiated `readwrite` on `books` object store, then another part that wants to do the same has to wait: the new transaction "hangs" till the first one is done. That can lead to strange delays if transactions take a long time.
373
+
Notably, `readwrite` transactions "lock" the stores for writing. So if one part of the application initiated `readwrite` on `books` object store, then another part that wants to do the same has to wait: the new transaction "hangs" till the first one is done. That can lead to strange delays if transactions take a long time.
The next `inventory.add` after `fetch``(*)` fails with an "inactive transaction" error, because the transaction is already committed and closed at that time.
794
794
795
-
The workaround is same as when working with native IndexedDB: either make a new transaction or just split things apart.
795
+
The workaround is the same as when working with native IndexedDB: either make a new transaction or just split things apart.
796
796
1. Prepare the data and fetch all that's needed first.
0 commit comments