-
Notifications
You must be signed in to change notification settings - Fork 7
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
[dagster-pipes-rust] 🔥 Simplify PipesMetadataValue
construction
#61
Conversation
PipesMetadata
constructionPipesMetadata
construction
PipesMetadata
constructionPipesMetadataValue
construction
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.
Really nice!
} | ||
} | ||
|
||
pub fn none() -> Self { |
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.
What do you think about this method name? Should it be none
, from_none
, or null
?
pub fn none() -> Self { | ||
PipesMetadataValue { | ||
raw_value: None, | ||
pipes_metadata_value_type: None, // TODO: Should this be `Some(Type::Null)`? |
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.
And should this be None
, or Some(Type::Null)
? Not sure what's the difference with either option though.
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.
I would go with:
pub fn null() -> Self {
PipesMetadataValue {
raw_value: None,
pipes_metadata_value_type: Some(Type::Null),
Function name: null
is similar to the python implementation here. Some(Type::Null)
follows the convention used by the other types in the rust implementation
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.
Done! Will merge in an hour, if everything's still looks good.
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.
LGTM!
Summary & Motivation
Fixes #46.
Approach
From<T>
trait wherever possible, allowing native types to be converted usingPipesMetadataValue::from(10)
. This has been implemented forf64
,i64
,bool
,String
,HashMap
andVec
.dagster_run
,timestamp
,null
), a::from_*
method is used instead. For example,PipesMetadataValue::from_asset("my_asset")
.Alternatives Considered: Use of Custom Types
The
RawValue
andType
enums fromjsonschema
have implicit connections to each other (e.g.Type::Int
should have aRawValue::Integer(...)
, and nothing else). Currently users are responsible for knowing this implicit mapping.I thought of using user-facing, custom
MetadataValue
enum that is separately defined fromjsonschema
. ThisMetadataValue
(different fromPipesMetadata
) is responsible forRawValue
andType
PipesMetadataValue
,RawValue
andType
.Something as follows:
In the end, the idea was scrapped because it introduces another enum that is very similar to existing public
jsonschema
types.How I Tested These Changes
cargo nextest
and no errors from compilerChangelog
Ensure that an entry has been created in
CHANGELOG.md
outlining additions, deletions, and/or modifications.See: keepachangelog.com