Skip to content

[ESDB-106-5] Bump up the chunk format version to 4 (Transformed)#4289

Merged
timothycoleman merged 1 commit intomasterfrom
chunk-v4
Jun 13, 2024
Merged

[ESDB-106-5] Bump up the chunk format version to 4 (Transformed)#4289
timothycoleman merged 1 commit intomasterfrom
chunk-v4

Conversation

@shaan1337
Copy link
Copy Markdown
Member

@shaan1337 shaan1337 commented Jun 11, 2024

Added: Chunk version 4 (Transformed) file format
Added: Support for forward compatibility in chunks

Thanks to @ylorph for the initial idea to bump up the chunk version and @timothycoleman and @sakno for their feedback.

@shaan1337 shaan1337 force-pushed the chunk-v4 branch 6 times, most recently from c0a8894 to 000d2b7 Compare June 12, 2024 08:32
@shaan1337 shaan1337 marked this pull request as ready for review June 12, 2024 08:34
Comment thread src/EventStore.Core/Exceptions/UnknownFileVersionException.cs Outdated
@shaan1337 shaan1337 force-pushed the chunk-v4 branch 2 times, most recently from d1ea1ac to 4f67f32 Compare June 12, 2024 10:11
@shaan1337 shaan1337 requested a review from ylorph June 12, 2024 10:11
@shaan1337 shaan1337 force-pushed the chunk-v4 branch 2 times, most recently from 009e649 to 7376737 Compare June 12, 2024 10:47
v4 basically represents the addition of the `TransformType` field.
We want to use v4 for all new chunks, whether a transformation is applied or not (i.e if we're using the `Identity` transform).

However, the existing chunk version verification code throws an exception on startup whenever a chunk with an unknown version is opened.
This means that old versions of the database will not be able to read/write to v4 chunks even if no transformation is applied.

To work around this, we implement forward compatibility in the following way:
- the current `Version` field is renamed to `MinCompatibleVersion`
- the next free slot of the chunk header is used to store the actual version (`Version`)

`MinCompatibleVersion` represents the minimum chunk version that the db needs to understand to be able to read/write to this chunk.
If a new chunk format is forward compatible, then `MinCompatibleVersion` can still point to an older version.
However, if a change is not forward compatible (e.g when a transform is applied), then `MinCompatibleVersion` must also be bumped up to a higher value.
@timothycoleman
Copy link
Copy Markdown
Contributor

This PR adds a second version field to the Chunk header. Now there are two:

  • MinimumCompatibleVersion (same position as the old Version field)
  • Version (new)

This facilitates the creation of forwards-compatible chunk versions and therefore facilitates rolling upgrades when the chunk version is changing.

When a new chunk has no transformation, it will have Version 4 (because it is) and MinVersion 3 (because old versions of ESDB will open it fine)

When a new chunk has a transformation, both versions will be 4. Old versions of ESDB will (correctly) refuse to open it.

The MinimumCompatibleVersion can be thought of as a promise of compatibility from a newer version of ESDB to an older version. In other circumstances this role could be played by a schema registry but that isn't applicable here.

@timothycoleman timothycoleman merged commit 897a665 into master Jun 13, 2024
@timothycoleman timothycoleman deleted the chunk-v4 branch June 13, 2024 06:52
@timothycoleman timothycoleman changed the title Bump up the chunk format version to 4 (Transformed) [ESDB-106-5] Bump up the chunk format version to 4 (Transformed) Jun 13, 2024
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.

3 participants