Versioning of the protocol-required database types #1552
Assignees
Labels
epic
An epic is a high-level master issue for large pieces of work.
SDK team
The issue is ready to be addressed by SDK team
upgradability
Comments
xgreenx
added
SDK team
xgreenx
changed the title
bvrooman
pushed a commit
that referenced
this issue
Jan 29, 2024
Related issues: - #1552 This PR converts the `Message` struct to an enum that can house multiple variants for versioning. Version variants contain an instance of a versioned struct, e.g., `MessageV1`. The `Message` enum exposes getters to the underlying data and abstracts the version. Setters are exposed only in test environments to allow tests to set up `Messages` in specific ways for the test. --------- Co-authored-by: Green Baneling <[email protected]>
xgreenx
pushed a commit
that referenced
this issue
Jan 31, 2024
Related issues: - #1552 --------- Co-authored-by: Matt <[email protected]>
xgreenx
added
the
epic
xgreenx
pushed a commit
that referenced
this issue
Feb 28, 2024
…ble (#1712) Related issues: - #1552 This PR remodels the existing `ContractUtxoInfo` type as an enum for the purpose of representing different versions of the data. This PR introduces `ContractUtxoInfoV1` which simply holds the existing data types for `ContractUtxoInfo`. This allows the `ContractsLatestUtxo` table to now use a versioned data type.
This was referenced Mar 18, 2024
crypto523
added a commit
to crypto523/fuel-core
that referenced
this issue
Oct 7, 2024
Related issues: - FuelLabs/fuel-core#1552
crypto523
added a commit
to crypto523/fuel-core
that referenced
this issue
Oct 7, 2024
Related issues: - FuelLabs/fuel-core#1552 This PR converts the `Message` struct to an enum that can house multiple variants for versioning. Version variants contain an instance of a versioned struct, e.g., `MessageV1`. The `Message` enum exposes getters to the underlying data and abstracts the version. Setters are exposed only in test environments to allow tests to set up `Messages` in specific ways for the test. --------- Co-authored-by: Green Baneling <[email protected]>
crypto523
added a commit
to crypto523/fuel-core
that referenced
this issue
Oct 7, 2024
…ble (#1712) Related issues: - FuelLabs/fuel-core#1552 This PR remodels the existing `ContractUtxoInfo` type as an enum for the purpose of representing different versions of the data. This PR introduces `ContractUtxoInfoV1` which simply holds the existing data types for `ContractUtxoInfo`. This allows the `ContractsLatestUtxo` table to now use a versioned data type.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Overview
In order to support upgrades, database types must support seamless versioning. For example, we must support the ability to change the key type and/or value type of a given table while maintaining backwards compatibility with existing data.
Database tables:
CompressedCoinContractsAssetsNote:ContractsAssets::Valuewill always be aWordValue:WordContractsAssetsMerkleDataNote:sparse::Primitivedoes not need to be versionedValue:fuel_merkle::sparse::PrimitiveSparseMerkleMetadata(Salt, Bytes32)ContractUtxoInfofor theContractsLatestUtxotable #1712)ContractUtxoInfoContractsRawCodeNote:ContractsRawCode::Valuewill always be a[u8]Value:[u8](write)OwnedValue:Contract(read)Bytes32ContractsStateMerkleDataNote:sparse::Primitivedoes not need to be versionedValue:fuel_merkle::sparse::PrimitiveSparseMerkleMetadataFuelBlockMerkleDataNote:binary::Primitivedoes not need to be versionedValue:fuel_merkle::binary::PrimitiveDenseMerkleMetadataBlockversionable #1593)CompressedBlockMessage#1632)Message()()TransactionImplementation
For each database type:
MakeMappable::KeyversionableMappable::ValueversionableUse
non_exhaustivefor enums.Note: Double-check that we spend one byte to store discriminant of the enum
The text was updated successfully, but these errors were encountered: