Reasoning behind indexedDB versioning

Question

So, the last 2 weeks I have been fighting with indexedDB and one of two recurring questions that keep popping up is why indexedDB has to use/present it's entire versioning system? I do understand that in certain very specific cases it's a nice thing to have, but in those cases an if(localstorage.dbversion <= ...) would do, so is there some reason in respect to browser implementations/optimalizations that require this roundabout¹ system? Or does it make indexedDB far more efficient or something?

¹ Roundabout because for example in onupgradeneeded you get the transaction from event.target.transaction whereas in onsuccess you get it from the result.transaction(). And there are countless of other more complex examples. (Such as cases where createStore is called in response to various huge (too big to keep it all in memory) ajax calls))

Answer 1

There are two schools of coping with changing database schemas in application logic:

1. Put if/then statements in the application logic to deal with the different versions of the database schema and upgrade the schema out of band, or as in the case of typical key/value storage, never upgrade the database schema at all.
2. Always upgrade the database to the latest schema on application upgrade and only have a single version of the application logic.

IndexedDB implements the second strategy. The schema changes are logically contained inside the same commit that changes the application logic. When you deploy a new version of the application, it will call db.open and pass it the new schema version. onupgradeneeded fires when the stored db is an older version, and gives an opportunity to upgrade the database's schema to the new version before any other application logic runs.