Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Never throw VersionError #1880

Merged
merged 6 commits into from
Feb 7, 2024
Merged

Never throw VersionError #1880

merged 6 commits into from
Feb 7, 2024

Conversation

dfahlander
Copy link
Collaborator

  • Allow schema changes without version bump
  • Allow downgrades
  • Only require version bump when content upgrades are needed

…as long as they have a compatible schema.

A compatible schema does not need to have the same tables or indexes. They might differ quite a lot.
* Attaching an upgrader to one of them would mean that the upgrader runs even though the first one didn't request it. Therefore, this scenario should be avoided when having upgraders that modify content between versions.
* Schemas are not compatible if they index the same property or properties using different flags (unique or multiEntry)
* Schemas are not compatible if they have different primary keys

However, in most scenarios where we would fail opening one of the DBs, we will now succeed and be able to access the same data.
(Not just 10)
When native verno is incremented 10 times to the next 10 multiple, create a table $meta that contains the virtual version. Maintain that table and delete it when no longer needed.
@dfahlander dfahlander changed the title Never throw versionerror Never throw VersionError Jan 22, 2024
@dfahlander dfahlander merged commit 54a23fa into master Feb 7, 2024
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant