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

Versioning of the protocol-required database types #1552

Closed
17 tasks done
xgreenx opened this issue Dec 14, 2023 · 0 comments
Closed
17 tasks done

Versioning of the protocol-required database types #1552

xgreenx opened this issue Dec 14, 2023 · 0 comments
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
Copy link
Collaborator

xgreenx commented Dec 14, 2023

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:

Implementation

For each database type:

  • Make Mappable::Key versionable
  • Make Mappable::Value versionable

Use non_exhaustive for enums.

Note: Double-check that we spend one byte to store discriminant of the enum

@xgreenx xgreenx added SDK team The issue is ready to be addressed by SDK team upgradability labels Dec 14, 2023
@xgreenx xgreenx changed the title Versioning of the protocol required database types Versioning of the protocol-required database types Dec 14, 2023
bvrooman pushed a commit that referenced this issue Jan 26, 2024
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 <XgreenX9999@gmail.com>
xgreenx pushed a commit that referenced this issue Jan 31, 2024
Related issues:
- #1552

---------

Co-authored-by: Matt <54373384+matt-user@users.noreply.github.com>
@xgreenx xgreenx added the epic An epic is a high-level master issue for large pieces of work. label Feb 4, 2024
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 pushed a commit to crypto523/fuel-core that referenced this issue Oct 7, 2024
crypto523 pushed 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 <XgreenX9999@gmail.com>
crypto523 pushed 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
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
Projects
None yet
Development

No branches or pull requests

2 participants