-
Notifications
You must be signed in to change notification settings - Fork 42
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
⏱️ [Do not merge]: Release experimental interop methods to stable #192
base: main
Are you sure you want to change the base?
Conversation
/fix-pr
|
|
# Partially update the configuration: | ||
source_connector.update_configuration( | ||
{"count": 300}, | ||
merge=True, |
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.
@aaronsteers How do you envision merge
being different from update_existing
?
In my mind, those sound like the same thing. Can we use update_existing
in both places?
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.
Hi, @alex-gron. The "update_existing" was/is planned for a "deploy*()" verb - where a False
value would fail if the resource already exists - rather than update it.
In this context "merge" is in the context of changes to settings - where 'merge=true' means we want to merge the provided setting with existing settign, and 'merge=false' would mean we replace all non-provided keys with the provided ones. This is useful when you want to change only one setting without modifying others. Especially useful when we don't want to re-supply creds each time we update non-secret config values.
No description provided.