There are two types of databases: A migratable one and a legacy one.
The legacy database does not know of its migration state (no migrations applied). Therefore on the first usage, the database gets prepared for migration. This does the following steps:
creating version_history table
inserting Initial into it if the database matches the legacy schema (which should be the case)
Afterward, the table gets migrated to the latest migration like a migratable table.
The migratable database updates to the latest version once the application starts (first usage of the database) so there are no conflicts with "too new code". The migrated database gets only saved if the user saves its actions. So there may be a performance penalty (depending on the state of the database) if the user does not save his database once it gets migrated.
Currently, there is no feedback for the user to know that the database got migrated. This might be ok because the most frequent use case of this app is creating changing the existing database and read from it. So most users probably safe every 1-2 times they open up Mercury.
More information about how the migrator actually works can be found in its file under src/util/migrator.js
relates to #17
Migrator works as follows:
There are two types of databases: A migratable one and a legacy one.
version_historytableInitialinto it if the database matches the legacy schema (which should be the case) Afterward, the table gets migrated to the latest migration like a migratable table.Currently, there is no feedback for the user to know that the database got migrated. This might be ok because the most frequent use case of this app is creating changing the existing database and read from it. So most users probably safe every 1-2 times they open up Mercury.
More information about how the migrator actually works can be found in its file under
src/util/migrator.js