-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
☝🏼 Upgrade all connectors (0.2.0) so protocol allows future / unknown properties #2238
☝🏼 Upgrade all connectors (0.2.0) so protocol allows future / unknown properties #2238
Conversation
I would need some initial approval and then I will start publishing new connectors along with migration script if this is the proper path we want to take. |
private static final ObjectWriter OBJECT_WRITER = OBJECT_MAPPER.writer(new JsonPrettyPrinter()); | ||
|
||
private static ObjectMapper initMapper() { | ||
final ObjectMapper result = new ObjectMapper(); | ||
result.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false); |
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.
- if in an object has
additionalProperties=false
, does this override it? or it his just overriding default behavior? - shouldn't be be changing the
additionalProperties
field in objects as well (or instead, depending on the answer to the first question)?
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.
To @cgardens point. There are 2 parts to allowing unknown properties:
- Ensure our Json SerDe accepts it
- Ensure our Json Schema validation accepts it
The PR only address the first point.
@cgardens I don't think your first point matter since additionalProperties
only makes sense once the model goes through validation.
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 additionalProperties
fields seem to influence only the JSON Schema validation as explained by Michel (which results in modifications to generated files for pydantic only?)
The Jackson SerDe operations are only configured by the ObjectMapper feature configure call.
- Anyway, I ran a manual test where I've tried building a docker image / artifact of a connector from this branch.
- Then I tested with modifications to the protocol (on top of the Step 2: Add Namespace to Airbyte Protocol #2228 branch changes)
- I verified that JSON validation in the connector works thanks to this PR. (Connectors with versions 0.1.X would fail)
- So everything is able to run normally (even though the connector is not supposed to support namespace fields yet)
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.
are you saying this change isn't necessary or that this change is what makes this possible? if you know what's going on here then i'm sure it's fine. i'm not fully understanding your last comment though.
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.
Yes, these are the changes that make it possible
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.
Once you've also addressed the validation and updated all the connectors that need it, I think the PR is good to go.
private static final ObjectWriter OBJECT_WRITER = OBJECT_MAPPER.writer(new JsonPrettyPrinter()); | ||
|
||
private static ObjectMapper initMapper() { | ||
final ObjectMapper result = new ObjectMapper(); | ||
result.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false); |
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.
To @cgardens point. There are 2 parts to allowing unknown properties:
- Ensure our Json SerDe accepts it
- Ensure our Json Schema validation accepts it
The PR only address the first point.
@cgardens I don't think your first point matter since additionalProperties
only makes sense once the model goes through validation.
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 we don't need to copy the full definitions file. other than that looks good.
airbyte-migration/src/main/java/io/airbyte/migrate/migrations/MigrationV0_17_0.java
Outdated
Show resolved
Hide resolved
...n/src/main/resources/migrations/migrationV0_17_0/airbyte_config/destination_definitions.yaml
Outdated
Show resolved
Hide resolved
private static final ObjectWriter OBJECT_WRITER = OBJECT_MAPPER.writer(new JsonPrettyPrinter()); | ||
|
||
private static ObjectMapper initMapper() { | ||
final ObjectMapper result = new ObjectMapper(); | ||
result.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false); |
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.
are you saying this change isn't necessary or that this change is what makes this possible? if you know what's going on here then i'm sure it's fine. i'm not fully understanding your last comment though.
airbyte-migration/src/main/java/io/airbyte/migrate/migrations/MigrationV0_17_0.java
Show resolved
Hide resolved
I understand why you want to write a migration. I didn't know we were going to automatically force upgrade connectors. I like the idea though and it seems like a good choice that saves customers headache in this case. |
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 % charles comments
airbyte-integrations/connectors/source-jdbc/src/main/resources/jdbc_models/jdbc_models.yaml
Outdated
Show resolved
Hide resolved
/publish connector=connectors/source-appstore-singer
|
/publish connector=connectors/source-braintree-singer
|
/publish connector=connectors/destination-postgres
|
/publish connector=connectors/source-drift
|
/publish connector=connectors/source-exchangeratesapi-singer
|
/publish connector=connectors/source-facebook-marketing
|
/publish connector=connectors/source-file
|
/publish connector=connectors/source-freshdesk
|
/publish connector=connectors/source-github-singer
|
/publish connector=connectors/source-google-adwords-singer
|
/publish connector=connectors/destination-csv
|
/publish connector=connectors/destination-jdbc
|
/publish connector=connectors/destination-local-json
|
/publish connector=connectors/destination-meilisearch
|
/publish connector=connectors/destination-redshift
|
/publish connector=connectors/destination-snowflake
|
/test connector=source-drift
|
What
This PR unblocks #2228 which needs to add new properties to the protocol.
However, the current connectors are throwing JSON validation errors if we try to evolve the protocol with new properties as they are currently unknown to previously released connectors.
How
Describe the solution
Connectors should accept new properties (in case we add new features in the future) and continue working while ignoring those new properties.
This PR isn't introducing new actual features, it is just making sure that after this being merged, every source connectors will be able to properly run even if the protocol is changed in the future
Pre-merge Checklist
Recommended reading order
airbyte-commons/src/main/java/io/airbyte/commons/json/Jsons.java
airbyte-migration/src/main/java/io/airbyte/migrate/migrations/MigrationV0_17_0.java