fix: Change options for new client#603
Conversation
⏱️ Benchmark results
|
|
Now that Im thinking more about it I think we might have a problem in our incremental syncing approach. If we specify incremental, only incremental tables should be synced as otherwise it can cause issues with destinations such as gcs. also, on the destination side we always don't delete incremental tables which basically now we disabled an option of So I think if |
@yevgenypats what kind of issues are you thinking about here? Maybe let's sync up on this if you have time later :) |
|
@yevgenypats backend could've been |
|
I don't think incremental-only should be automatically decided based on backend. If the user wants to sync incrementals on short periods but don't spam the full resources, they can have separate configs and use |
hermanschaaf
left a comment
There was a problem hiding this comment.
Maybe let's catch up about the new changes? I think we should consider some alternatives
| // Enable incremental syncing for tables that supports that | ||
| Incremental Incremental `json:"incremental,omitempty"` | ||
| // Sync on | ||
| OnlyIncrementalTables bool `json:"only_incremental_tables,omitempty"` |
There was a problem hiding this comment.
What is the use case for the OnlyIncrementalTables boolean? I don't understand why the same couldn't be achieved by splitting your config into incremental / non-incremental tables.
There was a problem hiding this comment.
It would be hard to determine which tables are incremental and generate a config and keep it up to date. This way you can have one config with all tables, fetched daily, and another one, fetched hourly, updating only incrementals (taking shorter bursts, not wasting API limits and other resources)
There was a problem hiding this comment.
True, but I think keeping your list of tables up-to-date (which to include, which to skip) and how regularly you want to sync each is a problem separate from incremental-ness, adding this one boolean is not going to solve it except maybe for a narrow use case
specs/incremental.go
Outdated
| func (r *Incremental) UnmarshalJSON(data []byte) (err error) { | ||
| var registry string | ||
| if err := json.Unmarshal(data, ®istry); err != nil { | ||
| return err | ||
| } | ||
| if *r, err = IncrementalFromString(registry); err != nil { | ||
| return err | ||
| } | ||
| return nil | ||
| } |
There was a problem hiding this comment.
| func (r *Incremental) UnmarshalJSON(data []byte) (err error) { | |
| var registry string | |
| if err := json.Unmarshal(data, ®istry); err != nil { | |
| return err | |
| } | |
| if *r, err = IncrementalFromString(registry); err != nil { | |
| return err | |
| } | |
| return nil | |
| } | |
| func (r *Incremental) UnmarshalJSON(data []byte) (err error) { | |
| var incremental string | |
| if err := json.Unmarshal(data, &incremental); err != nil { | |
| return err | |
| } | |
| if *r, err = IncrementalFromString(incremental); err != nil { | |
| return err | |
| } | |
| return nil | |
| } |
specs/incremental.go
Outdated
| case "both": | ||
| return IncrementalBoth, nil | ||
| default: | ||
| return IncrementalNone, fmt.Errorf("unknown registry %s", s) |
There was a problem hiding this comment.
| return IncrementalNone, fmt.Errorf("unknown registry %s", s) | |
| return IncrementalNone, fmt.Errorf("unknown incremental value %s", s) |
specs/incremental.go
Outdated
| IncrementalNone Incremental = iota | ||
| IncrementalTablesOnly | ||
| IncrementalBoth |
There was a problem hiding this comment.
What is the behavior expected to be for all these settings? What is the difference between setting IncrementalTablesOnly here and using the OnlyIncrementalTables boolean at the source spec level?
|
Removed Incremental per discussion and using only |
internal/servers/destinations.go
Outdated
| sourceSpec = specs.Source{ | ||
| Name: sourceName, | ||
| } |
There was a problem hiding this comment.
Why are we overwriting sourceSpec, shortly after unmarshaling from r.SourceSpec?
There was a problem hiding this comment.
good catch. a copy paste from the previous if
hermanschaaf
left a comment
There was a problem hiding this comment.
Looks good, just had the one question about overwriting the variable shortly after unmarshalling it
🤖 I have created a release *beep* *boop* --- ## [1.25.1](v1.25.0...v1.25.1) (2023-01-14) ### Bug Fixes * Change options for new client ([#603](#603)) ([f548a54](f548a54)) * PK Addition Order ([#607](#607)) ([eff40e7](eff40e7)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
I think I missed it in the review but the api should include an option struct rather then the
...optionas otherwise it's just introduce un-necessary boilerplate for each client.Also, I've added BackendNone as otherwise there is no way to specify that you don't want incremental syncing.