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.

Sign up for GitHub

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

Jump to bottom

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
@bvrooman
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 •
edited by bvrooman
Loading

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 bvrooman mentioned this issue Jan 25, 2024
Merged
bvrooman pushed a commit that referenced this issue Jan 26, 2024
feat: Versionable CompressedCoin (#1628)
2eaa6d4 
Related issues:
- #1552
@bvrooman bvrooman mentioned this issue Jan 27, 2024
Merged
bvrooman pushed a commit that referenced this issue Jan 29, 2024
@xgreenx
feat: Versionable Message (#1632)
3fdd33d 
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>
@bvrooman bvrooman mentioned this issue Jan 30, 2024
Merged
xgreenx pushed a commit that referenced this issue Jan 31, 2024
@matt-user
feat: Versionable Merkle metadata (#1639)
bc8780c 
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
@bvrooman bvrooman mentioned this issue Feb 10, 2024
Merged
@bvrooman bvrooman mentioned this issue Feb 28, 2024
Merged
xgreenx pushed a commit that referenced this issue Feb 28, 2024
feat: Versionable ContractUtxoInfo for the ContractsLatestUtxo ta…
d0edfb3 
…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
Closed
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@bvrooman bvrooman

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
Milestone
No milestone
Development

No branches or pull requests
2 participants
@bvrooman @xgreenx