fix!: Update all AWS Client Versions#2410
Conversation
| { | ||
| Name: "file_system_id", | ||
| Type: schema.TypeString, | ||
| Resolver: schema.PathResolver("FileSystemId"), | ||
| }, |
There was a problem hiding this comment.
@hermanschaaf It looks like the codegen changed the order of the fields, does this break backwards compatability?
There was a problem hiding this comment.
Right now, with PostgreSQL being the only destination, I don't think it breaks backwards compatibility... However as we add more destinations this may become an issue (e.g. for a CSV destination it absolutely will break, and possibly for some other data lakes too)
| { | ||
| Name: "admin_contact", | ||
| Type: schema.TypeJSON, | ||
| Resolver: schema.PathResolver("AdminContact"), | ||
| }, |
There was a problem hiding this comment.
More re ordering of fields/columns
| |reseller|String| | ||
| |status_list|JSON| | ||
| |tech_contact|JSON| | ||
| |status_list|StringArray| |
There was a problem hiding this comment.
This looks like a breaking change (changing type JSON to StringArray). Not much we can do about it... but it should technically require a major version bump.
| { | ||
| Name: "status_list", | ||
| Type: schema.TypeJSON, | ||
| Type: schema.TypeStringArray, |
There was a problem hiding this comment.
@hermanschaaf - A StringArray is a subset of JSON, maybe we can override the codegen to keep it as a JSON?
There was a problem hiding this comment.
Indeed we can... although it is a different question from whether we should 🙂 Future cases will also inevitably arise where we don't have a backwards-compatible option. Plus, just because we keep the column JSON, doesn't mean users don't need to update their queries (since the contents will change). I'd rather indicate that with a major version bump.
Maybe we should do updates like these on a semi-regular schedule, but not so regularly so as to cause constant toil for users. Will need to think about this some more...
There was a problem hiding this comment.
This change only occurred because the codegen was using v1 of the AWS Go SDK which relied heavily on pointers rather than native go types like the AWS SDK Go V2 does
There was a problem hiding this comment.
Ah, I see! So it shouldn't happen too often then. That's good to know
There was a problem hiding this comment.
AWS is really good about not releasing breaking changes, so unless something in our codegen/sdk changes as then we should always be good regenerating the clients
|
@bbernays LGTM, there are just some conflicts to resolve now |
🤖 I have created a release *beep* *boop* --- ## [2.0.0](plugins-source-aws-v1.0.1...plugins-source-aws-v2.0.0) (2022-10-06) ### ⚠ BREAKING CHANGES * Update all AWS Client Versions (#2410) * Store some JSON columns as jsonb not as a text (#2463) ### Features * Add new fields to Lightsail and EC2 ([#2403](#2403)) ([7e3fc83](7e3fc83)) * **aws:** EMR Clusters to use PreResourceResolver ([#2411](#2411)) ([b01e6ca](b01e6ca)) * **aws:** Update cis 1.5.0 policy ([#1615](#1615)) ([0f64196](0f64196)) ### Bug Fixes * AWS codegen: fix ec2 naming ([#2473](#2473)) ([27dd558](27dd558)) * **deps:** Update plugin-sdk for aws to v0.12.3 ([#2383](#2383)) ([0ed4d5f](0ed4d5f)) * **deps:** Update plugin-sdk for aws to v0.12.4 ([#2394](#2394)) ([d8c9657](d8c9657)) * **deps:** Update plugin-sdk for aws to v0.12.6 ([#2416](#2416)) ([0539c03](0539c03)) * **deps:** Update plugin-sdk for aws to v0.12.7 ([#2445](#2445)) ([6e39611](6e39611)) * Store some JSON columns as jsonb not as a text ([#2463](#2463)) ([5da8a1f](5da8a1f)) * Update all AWS Client Versions ([#2410](#2410)) ([ca34f1c](ca34f1c)) * Update endpoints ([#2414](#2414)) ([62d8802](62d8802)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
Summary
aws-sdk-gotoaws-sdk-go-v2