chore: Improve clarity when using CatalogConfigs in CatalogBuilder
#1873
Conversation
jonathanc-n
left a comment
jonathanc-n
left a comment
There was a problem hiding this comment.
Just some comments to clarify to reviewers
liurenjie1024
left a comment
liurenjie1024
left a comment
There was a problem hiding this comment.
Thanks @jonathanc-n for this pr, I have some suggestions to improve the readability.
crates/catalog/glue/src/catalog.rs
Outdated
|
|
||
| impl GlueCatalogBuilder { | ||
| /// Get a mutable reference to the catalog configuration. | ||
| pub(crate) fn catalog_config(&mut self) -> &mut GlueCatalogConfig { |
There was a problem hiding this comment.
I'm not a big fan of such a change. I think a better approach would be following:
pub struct GlueCatalogBuilder {
name: Option<String>,
....
}
struct GlueCatalogConfig {
name: String
}This makes things easier to read, more importantly, the config class type safe. Builder struct need to store intermediate states, so it's reasonable to have it contains many optional fields. The config struct, which is finally built and verfied, should only contain valid states, e.g. it should no longer has unnecessary optional fields.
| } | ||
|
|
||
| /// Rest catalog configuration. | ||
| #[derive(Clone, Debug, TypedBuilder)] |
There was a problem hiding this comment.
Do we still need this TypedBuilder?
There was a problem hiding this comment.
Just some questions for this one. Would this be breaking? Should I change the builder functionality for RestCatalog to be similar to the other catalogs (ex. using the load function.? Do you know why the builder for this one is different from the other catalogs?
There was a problem hiding this comment.
I think it will not breaking since it's not public api. Is there any place actually using the generated builder of RestCatalogConfig?
2 participants
Which issue does this PR close?
CatalogBuilder.0more explicit #1862 .What changes are included in this PR?
Makes
CatalogConfigcalls more explicit.Are these changes tested?