Version numbers increased by 10

[Stretsh]

So imagine me seeing the database number for the first time, being 10. Huh? Test db, so I deleted it, and ran the app again: 10 again! Added version 2 in the code, and yes, db version shows 20... 23, just to see what will happen: 230!

I started looking around and found #59. Has me thinking...

@dfahlander said

... but I cannot change this beause is would affect all existing implementations.

How exactly would it affect all implementations? One might wanna think of a way to bring it back to using normal version numbers, but there might be pitfalls you see that could hinder this.

and then

I should add that the workaround is not implemented yet, and I will not prioritize it because it applies to a quite rare scenario, when you want to move objects from one store to another and then remove the old store.

I'm wondering if, almost 9 years later, a workaround for a very rare case in a pretty much obsolete browser will still be implemented. Maybe it's time to remove the confusion (something that I regret today because it confuse more than it give) in this awesome library.

I'm thinking: remove the * or / 10 and make the version in the code be in line with the actual db version.
For backward compatibility, notify the dev when they add a new upgrade. Like my example above, if I were to try db.version(24), throw an error or something, to let me know that the current actual db version is 230 and that needs to be regarded as my previous number.
Existing db.version() in the app can stay the same, until the next upgrade.

New implementations, like me, can then start fresh.

Just my thoughts. Thought I'd share this instead of just thinking about it.

[dfahlander]

Thanks for sharing these thoughts.

Sorry for a long answer. I tried to keep it short, but looking below, I obviously failed :-|

Version will be optional

The plans for next major version is to abstract the version number away and dynamically provide it. Version numbers only play a role when migrating the data. It's a big problem to switch back to a previous version of a published application as IndexedDB is designed. The app will fail because of specifying a version less than the currently installed version. The use case is that a test-version of an app needs to extend the schema, some canary user is put on the test version - then for some reason, it has to be drawn back to the last working version, but then the end user needs to delete IndexedDB in order to run the previous version again.

The idea is that it will be possible to omit the version number when specifying the schema and dexie will find out, when opening the database whether a version number increase is nescessary or not (depending if the declared schema differ from the installed schema)

Migrations

Named or numbered versions are great for migration purposes though (db.version().upgrade())! The plan is to continue support version and allow either a number or a string to specify the version. If providing a number that is above the installed version, we can use it like we do now. If providing a string, or a number that is less than the installed one, the behavior will depend on whether an upgrade is supposed to run or not. If no upgrader is attached, I see no reason for not just comparing the schema and upgrade dynamically if needed, storing the provided version in a meta table, to identify the intended version number of the provided schema. When the next version of the db is released for an app, dexie would be able to compute whether its upgrader should run or not, but inspecting the meta table.

Backward Compability is My Religion

It should still be possible to declare the version number and I am very much conservative regarding backward compatibility. It will be possible to use dexie the same way as before without having to change the code. Putting demands on all devs to update their code in order for it to work hurts more than it gains. Lib vendors often think this isn't a big deal, but for those out there that have tons of libraries to care about, where dexie is just one of them, it will certainly hurt having to debug and, google the reason for their app stopped working on an upgrade.

Support for downgrades

However, since we anyway will start opening the database dynamically we won't nescessary have to throw the VersionError when the user specified a version less that the installed one. We can downgrade the schema when a previous version is loaded. If an upgrader had run on the newer version, we could throw unless the upgrader statically declared the behavior of a downgrade - the downgrader must be declared and not be JS code because persisting JS code that would be executed could introduce security vulnerabilities.

In the end, as long as no migrations are needed between schema changes, specifying a version number should not be nescessary and switching back and forth between versions should not be a problem. But when migration is needed, a version number or string could identity the version and make the changes needed. To support downgrades from migrated databases, the upgrader could be accompanied with a downgrade specification such as a where-filter and a modification object, but not code.

Sorry to answer more than was asked for but this I wanted to explain the reasoning and reasoning for how this is planned to work.

[Stretsh]

No need to apologize for the length of your answer! It is actually appreciated, because I got a bit more insight into your thought process.

I don't know how you plan to approach this logic, but I kinda have the feeling you're trying figure out how to squeeze all this functionality into Dexie.version(). Looks like a lot is focused around versioning of the database and as you mention, there may be (probably more) cases where the database version might not even need to change from a Dexie point of view.

What if, while leaving Dexie.version() in place for backward compatibility, you extract the upgrade and downgrade processes (maybe even migration) to their own method on class Dexie? The logic for each would be specific to its use case, and you don't have to write extra logic to figure out what the user/dev is actually trying to do (like checking if a number or string is used in version() and run a set of instructions based on that).

Like many other libraries/frameworks, Dexie aims to make it easier to do tasks, that are cumbersome in the source. db.version(1).stores({ friends: '++id, name, age' }); is an example of how one line of code can replace a number of lines in the original source. The problem usually comes when more and more features are being added. The developer then tries to fit all these features into the concept as it is. This usually leads to syntaxes that become only relevant for the library, which means that developers need to learn the library specific syntax/jargon.

Extracting specific logic to its own function/method makes it clearer for the user (devs in this case) and cause less confusion. Dexie.version() is used for versioning. Dexie.upgrade() is used for when I need to upgrade. Dexie.downgrade() is used to downgrade. Dexie.migrate() is used for simple migration. Etcetera. No need to be forced to use Dexie.version() if I don't need to specify a specific version. No need for you to keep cramming features/logic into version(), that might need to be handled elsewhere. Upgrade, downgrade and migrate should be able to figure out versioning (maybe in combination with version()), if needed, but it might be something the user/dev doesn't need to be "bothered" with, unless they explicitly want to.

This is just me, thinking out loud. My apologies, if these ideas don't fit into (and could frustrate thought processes around) the concept of Dexie.