-
Notifications
You must be signed in to change notification settings - Fork 18
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-bigquery: don't serialize JSON nulls #2323
Changes from all commits
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 |
---|---|---|
@@ -1,4 +1,4 @@ | ||
package boilerplate | ||
package common | ||
|
||
import "strings" | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -8,6 +8,7 @@ import ( | |
|
||
"cloud.google.com/go/bigquery" | ||
storage "cloud.google.com/go/storage" | ||
"github.com/estuary/connectors/go/common" | ||
"github.com/estuary/connectors/go/dbt" | ||
boilerplate "github.com/estuary/connectors/materialize-boilerplate" | ||
sql "github.com/estuary/connectors/materialize-sql" | ||
|
@@ -16,7 +17,12 @@ import ( | |
"google.golang.org/api/option" | ||
) | ||
|
||
// Config represents the endpoint configuration for BigQuery. | ||
var featureFlagDefaults = map[string]bool{ | ||
// When set, object and array field types will be materialized as JSON | ||
// columns, instead of the historical behavior of strings. | ||
"objects_and_arrays_as_json": false, | ||
} | ||
|
||
type config struct { | ||
ProjectID string `json:"project_id" jsonschema:"title=Project ID,description=Google Cloud Project ID that owns the BigQuery dataset." jsonschema_extras:"order=0"` | ||
CredentialsJSON string `json:"credentials_json" jsonschema:"title=Service Account JSON,description=The JSON credentials of the service account to use for authorization." jsonschema_extras:"secret=true,multiline=true,order=1"` | ||
|
@@ -28,6 +34,12 @@ type config struct { | |
HardDelete bool `json:"hardDelete,omitempty" jsonschema:"title=Hard Delete,description=If this option is enabled items deleted in the source will also be deleted from the destination. By default is disabled and _meta/op in the destination will signify whether rows have been deleted (soft-delete).,default=false" jsonschema_extras:"order=7"` | ||
Schedule boilerplate.ScheduleConfig `json:"syncSchedule,omitempty" jsonschema:"title=Sync Schedule,description=Configure schedule of transactions for the materialization."` | ||
DBTJobTrigger dbt.JobConfig `json:"dbt_job_trigger,omitempty" jsonschema:"title=dbt Cloud Job Trigger,description=Trigger a dbt job when new data is available"` | ||
|
||
Advanced advancedConfig `json:"advanced,omitempty" jsonschema:"title=Advanced Options,description=Options for advanced users. You should not typically need to modify these." jsonschema_extra:"advanced=true"` | ||
} | ||
|
||
type advancedConfig struct { | ||
FeatureFlags string `json:"feature_flags,omitempty" jsonschema:"title=Feature Flags,description=This property is intended for Estuary internal use. You should only modify this field as directed by Estuary support."` | ||
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. Why not an advanced property specifically for materializing objects and arrays as strings without an exposed JSONSchema? 🤔 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 had this same thought initially, and there was some internal discussion about it here. The TL;DR is that there's a desire to standardize around using this feature flag convention for this sort of thing, as we have been & will be doing more of for changing behaviors of SQL captures. More specifically what I mean re: "this sort of thing" is controlling behaviors that we don't expect users to ever interact with directly, either for preserving existing compatibility, or selectively enabling new code paths. |
||
} | ||
|
||
func (c *config) Validate() error { | ||
|
@@ -162,6 +174,11 @@ func newBigQueryDriver() *sql.Driver { | |
"bucket_path": cfg.BucketPath, | ||
}).Info("creating bigquery endpoint") | ||
|
||
var featureFlags = common.ParseFeatureFlags(cfg.Advanced.FeatureFlags, featureFlagDefaults) | ||
if cfg.Advanced.FeatureFlags != "" { | ||
log.WithField("flags", featureFlags).Info("parsed feature flags") | ||
} | ||
|
||
return &sql.Endpoint{ | ||
Config: cfg, | ||
Dialect: bqDialect, | ||
|
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.
The name is fairly self-explanatory in this case, but I've been trying to maintain a convention of describing the impact of a flag here in the defaults map.
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.
That's a good idea, I added a comment here to explain what the flag does.