-
Notifications
You must be signed in to change notification settings - Fork 17
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
materialize-databricks: new connector #1021
Conversation
10b19c0
to
5e17779
Compare
5e17779
to
61d1ca5
Compare
c98fb69
to
3a25853
Compare
e071cc4
to
385e599
Compare
124e35d
to
48a85bc
Compare
What remains to be tested: since I have changed the logic of the CounterWriter, we need to test whether compression is still working fine. The non-compression case is working as I have tested it with Databricks. UPDATE: tested this by running bigquery's integration tests 👍🏽 |
da101e8
to
5362209
Compare
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.
Some initial comments/considerations - looking good so far, this one is a bit of a beast.
eb83e0f
to
e2ad00c
Compare
|
||
type tableConfig struct { | ||
Table string `json:"table" jsonschema:"title=Table,description=Name of the table" jsonschema_extras:"x-collection-name=true"` | ||
Schema string `json:"schema" jsonschema:"title=Schema,description=Schema where the table resides,default=default"` |
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.
For consistency with other materializations and usability, I suggest:
- Not setting a default for
schema
intableConfig
- Making
schema
optional intableConfig
- In
config
, makeschema_name
a required field (note: I am assuming that you can't connect without some kind of schema specified), and maybe make the name of the equivalent fields in thetableConfig
andconfig
be the same - In
(*config).Validate
, error ifschema_name
hasn't been provided - In
newTableConfig
, by default initialize the schema to the schema fromconfig
, which will be over-written if there is a presentschema
property in the raw json of the resource config when it is unmarshalled elsewhere
This would support the case where most bindings use the same schema as set in the endpoint-level config
, but just a few need to be edited to use a different schema, which can be done by just configuring it for those specific bindings. It would directly parallel the BigQuery and Snowflake materializations, which work in this way. As it is now, if you wanted to materialize all the bindings to a schema other than "default", you would need to set it for every single binding.
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 % remaining unresolved comments
Merging of this depends on gazette/core#352 so holding off until that PR is merged and landed |
Description:
Workflow steps:
(How does one use this feature, and how has it changed)
Documentation links affected:
(list any documentation links that you created, or existing ones that you've identified as needing updates, along with a brief description)
Notes for reviewers:
(anything that might help someone review this PR)
This change is