-
Notifications
You must be signed in to change notification settings - Fork 360
chore: Improve clarity when using CatalogConfigs in CatalogBuilder
#1873
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
base: main
Are you sure you want to change the base?
Changes from 1 commit
3071456
104ae32
400c6b6
dc2dde4
15e3d2d
46091ff
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -71,6 +71,24 @@ impl Default for RestCatalogBuilder { | |
| } | ||
| } | ||
|
|
||
| impl RestCatalogBuilder { | ||
| /// Get a mutable reference to the catalog configuration. | ||
| pub(crate) fn catalog_config(&mut self) -> &mut RestCatalogConfig { | ||
| &mut self.0 | ||
| } | ||
|
|
||
| /// Consume the builder and return the catalog configuration. | ||
| pub(crate) fn into_config(self) -> RestCatalogConfig { | ||
| self.0 | ||
| } | ||
|
|
||
| /// Configures the catalog with a custom HTTP client. | ||
| pub fn with_client(mut self, client: Client) -> Self { | ||
| self.catalog_config().client = Some(client); | ||
| self | ||
| } | ||
| } | ||
|
|
||
| impl CatalogBuilder for RestCatalogBuilder { | ||
| type C = RestCatalog; | ||
|
|
||
|
|
@@ -79,53 +97,46 @@ impl CatalogBuilder for RestCatalogBuilder { | |
| name: impl Into<String>, | ||
| props: HashMap<String, String>, | ||
| ) -> impl Future<Output = Result<Self::C>> + Send { | ||
| self.0.name = Some(name.into()); | ||
| self.catalog_config().name = Some(name.into()); | ||
|
|
||
| if props.contains_key(REST_CATALOG_PROP_URI) { | ||
| self.0.uri = props | ||
| self.catalog_config().uri = props | ||
| .get(REST_CATALOG_PROP_URI) | ||
| .cloned() | ||
| .unwrap_or_default(); | ||
| } | ||
|
|
||
| if props.contains_key(REST_CATALOG_PROP_WAREHOUSE) { | ||
| self.0.warehouse = props.get(REST_CATALOG_PROP_WAREHOUSE).cloned() | ||
| self.catalog_config().warehouse = props.get(REST_CATALOG_PROP_WAREHOUSE).cloned() | ||
| } | ||
|
|
||
| // Collect other remaining properties | ||
| self.0.props = props | ||
| self.catalog_config().props = props | ||
| .into_iter() | ||
| .filter(|(k, _)| k != REST_CATALOG_PROP_URI && k != REST_CATALOG_PROP_WAREHOUSE) | ||
| .collect(); | ||
|
|
||
| let config = self.into_config(); | ||
| let result = { | ||
| if self.0.name.is_none() { | ||
| if config.name.is_none() { | ||
| Err(Error::new( | ||
| ErrorKind::DataInvalid, | ||
| "Catalog name is required", | ||
| )) | ||
| } else if self.0.uri.is_empty() { | ||
| } else if config.uri.is_empty() { | ||
| Err(Error::new( | ||
| ErrorKind::DataInvalid, | ||
| "Catalog uri is required", | ||
| )) | ||
| } else { | ||
| Ok(RestCatalog::new(self.0)) | ||
| Ok(RestCatalog::new(config)) | ||
| } | ||
| }; | ||
|
|
||
| std::future::ready(result) | ||
| } | ||
| } | ||
|
|
||
| impl RestCatalogBuilder { | ||
| /// Configures the catalog with a custom HTTP client. | ||
| pub fn with_client(mut self, client: Client) -> Self { | ||
| self.0.client = Some(client); | ||
| self | ||
| } | ||
| } | ||
|
|
||
| /// Rest catalog configuration. | ||
| #[derive(Clone, Debug, TypedBuilder)] | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we still need this
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it will not breaking since it's not public api. Is there any place actually using the generated builder of RestCatalogConfig? |
||
| pub(crate) struct RestCatalogConfig { | ||
|
|
||
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'm not a big fan of such a change. I think a better approach would be following:
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.
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.
Made the changes in 400c6b6