Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Postgres config 3605 #3862
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
Postgres config 3605 #3862
Changes from 4 commits
08122e9
ffe739e
f7031e6
1842548
a57b26e
c6fba44
98a1133
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
is this abstraction saving us all that much? i'm not super convinced it's getting us much over just having
PostgresConfigPersistence
. I guess we are mainly avoiding duplicating the get and list queries. it's probably little enough code that i would be just okay with duplicating.it's just a guess on my part though, so please feel free to stick with this if you think it's worth it, but i wanted to share my perception.
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 think it is idiomatic in PG to use lower cased (snake cased) table names and column names.
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.
=>
setup
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.
when will this be called?
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.
It's to be called by whatever code initializes the storage system for the first time, and also by the tests of course. That part isn't hooked up to any existing code yet other than the test.
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 appreciate the attempt to factor out this configuration component here, but I think this probably a place where we want to keep the code paths separate.
here's how i'm thinking about it... the config (a json blob) that we use in the postgres source, postgres destination, and the database that is used in airbyte-core are all different. at least in the case of source and destination, their configuration objects are declared separately.
this is to bringing to light one thing, which is putting these naked
JsonNode
in interfaces is kinda dangerous... they're almost no better than just doing typeObject
. this is a bit more tolerable in the connector world because (theoretically) the objects are validated (although as we discussed in your last PR, the tests don't check for it explicitly).In general where possible we should reduce the use of just
JsonNode
, and I think in this case the schema of the object is knowable enough that we can do that.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.
by convention we try to avoid the
XYZ.*
imports (when you use the create test macro in intellij it does this automatically unfortunately. not sure how to get around it.)