-
Notifications
You must be signed in to change notification settings - Fork 123
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
Feature: Versioned package substates #1358
Conversation
Benchmark for a3f2a35Click to view benchmark
|
OriginalCode, | ||
InstrumentedCode, | ||
} | ||
macro_rules! blueprint_partition_offset { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we remove these mappings as discussed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not easily - these are currently used by the TypedSubstate mapping, which we need for reverse-mapping the substate stream to typed substates.
@@ -0,0 +1,157 @@ | |||
use crate::internal_prelude::*; | |||
|
|||
pub trait FeatureSetResolver: Debug { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we rename to something like HasFeatures
, Resolver
seems to imply a process which takes input.
|
||
/// For feature checks against a non-inner object | ||
#[derive(Debug)] | ||
pub enum FeatureChecks<TOwn: FeatureSetResolver> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed can we remove FeatureChecks
?
|
||
/// Generates types and typed-interfaces for native blueprints, their | ||
/// state models, features, partitions, and their interaction with | ||
/// the substate store. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update comment to remove "partitions and their interactions with the substate store"
/// For each collection key, the following types will be created: | ||
/// * `<BlueprintIdent><CollectionIdent>KeyPayload` - a new type for the key payload (eg includes the u16 for a sorted index key) | ||
/// | ||
/// The content of each of the above can take a number of forms. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Except for keys right?
blueprint_version_definitions: KeyValue { | ||
entry_ident: BlueprintVersionDefinition, | ||
key_type: { | ||
kind: Static, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does key_type have another kind besides Static
?
a10d0ff
to
4518cf8
Compare
Summary
A slightly stripped back #1318 which avoids generating the
_StateInit
and the_Partition
models.I've generally tried to avoid changing things that don't need changing, but I don't think there's anything particularly controversial left?
This implements for packages, and in a separate PR, I'll implement for other native blueprints.
Update Recommendations
For Internal Integrators
I'll merge this into the node. This shouldn't have any impact outside of Scrypto and Node.