- `error`: opening failed.

- `upgradeneeded`: database is ready, but its version is outdated (see below).

Unlike server-side databases, IndexedDB is client-side, the data is stored in the browser, so we, developers, don't have direct access to it. But when we publish a new version of our app, we may need to update the database.

When we first publish our app, we open it with version `1` and perform the initialization in `upgradeneeded` handler:

// the existing database version is less than 2 (or it doesn't exist)

switch(db.version) { // existing db version

So, in `openRequest.onupgradeneeded` we update the database. Soon we'll see how it's done. And then, only if its handler finishes without errors, `openRequest.onsuccess` triggers.

```warn header="Can we open an old version?"

Now what if we try to open a database with a lower version than the current one? E.g. the existing DB version is 3, and we try to `open(...2)`.

That's an error, `openRequest.onerror` triggers.

Such thing may happen if the visitor loaded an outdated code, e.g. from a proxy cache. We should check `db.version`, suggest him to reload the page. And also re-check our caching headers to ensure that the visitor never gets old code.

```

### Parallel update problem

As we're talking about versioning, let's tackle a small related problem.

Let's say, a visitor opened our site in a browser tab, with database version 1.

Then we rolled out an update, and the same visitor opens our site in another tab. So there are two tabs, both with our site, but one has an open connection with DB version 1, while the other one attempts to update it in `upgradeneeded` handler.

The problem is that a database is shared between two tabs, as that's the same site, same origin. And it can't be both version 1 and 2. To perform the update to version 2, all connections to version 1 must be closed.

In order to organize that, the `versionchange` event triggers an open database object when a parallel upgrade is attempted. We should listen to it, so that we should close the database (and probably suggest the visitor to reload the page, to load the updated code).

If we don't close it, then the second, new connection will be blocked with `blocked` event instead of `success`.

Here's the code to do that:

```js

let openRequest = indexedDB.open("store", 2);

openRequest.onupgradeneeded = ...;

openRequest.onerror = ...;

openRequest.onsuccess = function() {

let db = openRequest.result;

*!*

db.onversionchange = function() {

db.close();

alert("Database is outdated, please reload the page.")

};

*/!*

// ...the db is ready, use it...

};

*!*

openRequest.onblocked = function() {

// there's another open connection to same database

// and it wasn't closed after db.onversionchange triggered for them

};

*/!*

```

Here we do two things:

1. Add `db.onversionchange` listener after a successful opening, to be informed about a parallel update attempt.

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

There are other variants. For example, we can take time to close things gracefully in `db.onversionchange`, prompt the visitor to save the data before the connection is closed. The new updating connection will be blocked immediatelly after `db.onversionchange` finished without closing, and we can ask the visitor in the new tab to close other tabs for the update.

Such update collision happens rarely, but we should at least have some handling for it, e.g. `onblocked` handler, so that our script doesn't surprise the user by dying silently.

To store something in IndexedDB, we need an *object store*.

For small databases the second variant may be simpler.

let openRequest = indexedDB.open("db", 2);

- `IDBKeyRange.lowerBound(lower, [open])` means: `≥lower` (or `>lower` if `open` is true)

- `IDBKeyRange.upperBound(upper, [open])` means: `≤upper` (or `<upper` if `open` is true)

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

// get books with 'css' <= id <= 'html'

// get books with id < 'html'

books.getAll(IDBKeyRange.upperBound('html', true))

// get all keys: id > 'js'

// find books where price <= 5

For cursors over indexes, `cursor.key` is the index key (e.g. price), and we should use `cursor.primaryKey` property for the object key:

The basic usage can be described with a few phrases:

- Create object storages and indexes in `onupgradeneeded` handler or perform version update if needed.