# What should be the default value of a missing metadataVersion key in an new database?
**URL:** https://forums.foundationdb.org/t/what-should-be-the-default-value-of-a-missing-metadataversion-key-in-an-new-database/1819
**Category:** Using FoundationDB
**Created:** [December 6, 2019, 1:22pm UTC](https://forums.foundationdb.org/t/what-should-be-the-default-value-of-a-missing-metadataversion-key-in-an-new-database/1819 "2019-12-06T13:22:18Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@KrzysFR](https://forums.foundationdb.org/u/KrzysFR)
#### Post date: [December 6, 2019, 1:22pm UTC](https://forums.foundationdb.org/t/what-should-be-the-default-value-of-a-missing-metadataversion-key-in-an-new-database/1819/1 "2019-12-06T13:22:18Z")
When a new cluster is created, it is possible that the `\xFF/metadataVersion` system key is not yet present.
I’m adding a bunch of API to return the value of that field as a versionstamp, and was wondering what should be the default value if the key is not present?
Previously, I was returning the bytes as-is, so the value was “null”. I’m considering returning the empty versionstamp (10 zero-bytes) instead. Is this a good default value?
Bonus question: is it ok to expect the value of the metadata version key to always to a valid versionstamp (10 and only 10 bytes) or can it be something else?
---
### Author:  [@andrew.noyes](https://forums.foundationdb.org/u/andrew.noyes)
#### Post date: [December 6, 2019, 11:45pm UTC](https://forums.foundationdb.org/t/what-should-be-the-default-value-of-a-missing-metadataversion-key-in-an-new-database/1819/2 "2019-12-06T23:45:44Z")
> [@KrzysFR](#):
>
> Bonus question: is it ok to expect the value of the metadata version key to always to a valid versionstamp (10 and only 10 bytes) or can it be something else?
You couldn’t really write anything else by accident: this is guarded in the client. See [https://github.com/apple/foundationdb/blob/d94a1dfef251cc0fd4bf94c4bb80416796d48e6a/fdbclient/ReadYourWrites.actor.cpp#L1530](https://github.com/apple/foundationdb/blob/d94a1dfef251cc0fd4bf94c4bb80416796d48e6a/fdbclient/ReadYourWrites.actor.cpp#L1530) and [https://github.com/apple/foundationdb/blob/d94a1dfef251cc0fd4bf94c4bb80416796d48e6a/fdbclient/ReadYourWrites.actor.cpp#L1604](https://github.com/apple/foundationdb/blob/d94a1dfef251cc0fd4bf94c4bb80416796d48e6a/fdbclient/ReadYourWrites.actor.cpp#L1604). Maybe if someone were using an old client library without that check and enabled the access system keys option in their transaction for some reason?
> [@KrzysFR](#):
>
> Previously, I was returning the bytes as-is, so the value was “null”. I’m considering returning the empty versionstamp (10 zero-bytes) instead. Is this a good default value?
I think 10 zero-bytes is a fine default for the intended use, since it’s different from any possible version stamp set in the normal way.
---
### Author:  [@KrzysFR](https://forums.foundationdb.org/u/KrzysFR)
#### Post date: [December 7, 2019, 10:56am UTC](https://forums.foundationdb.org/t/what-should-be-the-default-value-of-a-missing-metadataversion-key-in-an-new-database/1819/3 "2019-12-07T10:56:37Z")
> [@andrew.noyes](#):
>
> You couldn’t really write anything else by accident: this is guarded in the client.
Yes but the code does not seem to check the offset of the versionstamp? Could I write a 100-byte value with a versionstamp at offset 42 with a SetVersionstampedValue and still succeed the check?
I’m unsure if I can safely change the signature of accessing the metadataVersion in my binding to return a VersionStamp, instead of returning a byte buffer and only rely on binary ordering to compare it to the previously cached value.
By the way, if SetVersionstampedValue with offset non-zero is allowed for this key, won’t this break cache layers which rely on ordering, since the leading bytes could be whatever ?
---
### Author:  [@andrew.noyes](https://forums.foundationdb.org/u/andrew.noyes)
#### Post date: [December 9, 2019, 5:08pm UTC](https://forums.foundationdb.org/t/what-should-be-the-default-value-of-a-missing-metadataversion-key-in-an-new-database/1819/4 "2019-12-09T17:08:07Z")
> [@KrzysFR](#):
>
> if SetVersionstampedValue with offset non-zero is allowed for this key
SetVersionstampedValue with a non-zero offset is not allowed for this key. Only this exact value is allowed: [https://github.com/apple/foundationdb/blob/dbfa3dc217f09757ba996d20bdbe1c215d8fc45f/fdbclient/SystemData.cpp#L683](https://github.com/apple/foundationdb/blob/dbfa3dc217f09757ba996d20bdbe1c215d8fc45f/fdbclient/SystemData.cpp#L683), and that value specifies offset zero.
---
### Author:  [@KrzysFR](https://forums.foundationdb.org/u/KrzysFR)
#### Post date: [December 9, 2019, 5:15pm UTC](https://forums.foundationdb.org/t/what-should-be-the-default-value-of-a-missing-metadataversion-key-in-an-new-database/1819/5 "2019-12-09T17:15:28Z")
I now see the check for the operand value in [https://github.com/apple/foundationdb/blob/07331ab5fd0687ef790d291c30034e7ef675cbcd/fdbclient/ReadYourWrites.actor.cpp#L1531](https://github.com/apple/foundationdb/blob/07331ab5fd0687ef790d291c30034e7ef675cbcd/fdbclient/ReadYourWrites.actor.cpp#L1531)
This means I have to change some things in my binding because the spot occupied by a versionstamp could be any bytes, while here I have to force it to all-zeroes 🙂
So the good news is that I can safely change the API to expose the metadata version as a parsed versionstamp (with value “0” if missing), instead of a byte buffer.