[BEAM-13416] Introduce Schema provider for AWS model classes extending SdkPojo #16947

mosche · 2022-02-25T12:04:20Z

@echauchot @aromanenko-dev Not really a PR (yet), I was just looking to understand the usage of schemas vs coders better.
The (most) interesting part here is probably SdkPojoSchema that works for all the generated AWS models in the SDK v2 (though, in some cases recursive types are used which obviously impose a challenge).

I wasn't able to find a lot of good technical documentation (design decisions) for schemas in Beam, though definitely see the value over low level coders! It seems to make sense to bother users as little as possible with coders and not expose these on any public API (M11). Currently coders are all over the place for AWS IOs, with this it seems feasible to drop them (or deprecate).

Though, I was wondering a couple of things:

Looks like I cannot register a provider for an interface (SdkPojo), that means I have to "announce" it globally using an auto service.
Is there a way a Sink/ WriteIO can set the coder for it's input like that can be done for a Source on the output? Looks like it's only possible to register such a coder globally, regardless if that sink is used or not.
I noticed that a RowCoder cannot be automatically inferred for a row despite every row carrying its schema. That makes sense given runners may use the schema ahead of time for query planning. But it made me wonder if there's any relationship between the schema of the row coder and the runtime schema enforced...

If you have any good resources on the topic, I'd be happy to hear ...

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

Choose reviewer(s) and mention them in a comment (R: @username).
Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
Update CHANGES.md with noteworthy changes.
If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

mosche · 2022-02-25T12:35:18Z

@pabloem I remember you made related changes on your recent PR to JdbcIO to add support for generic partitioners. I wonder if you have pointers to documentation or simply advice on the topic :)

aromanenko-dev · 2022-02-28T17:45:13Z

@reuvenlax Could you advise on this please?

reuvenlax · 2022-02-28T17:47:23Z

Can you explain what SdkPojoSchema is? We already have an optimized Pojo schema provider (JavaFieldSchema)

mosche · 2022-02-28T18:49:28Z

@reuvenlax JavaFieldSchema doesn't work for AWS models, the sdk v2 uses immutable objects based on builders / final fields. SdkPojo is the common interface of all of these models.

mosche · 2022-02-28T18:53:43Z

SdkPojoSchema uses the metadata exposed by SdkPojos to read fields and write them via an intermediate builder.

reuvenlax · 2022-02-28T18:54:16Z

JavaFieldSchema should work for immutable objects with builders too. Can we elucidate what the gap is there? JavaFieldSchema is fairly optimized using bytecode generation, so it doesn't have to convert back and forth to a Row object (rather the Row object simply forwards it accesses to direct accesses of the POJO using bytecode). If we are able to leverage that, it will be a significant performance advantage over the SdkPojo schema provider.

…

On Mon, Feb 28, 2022 at 10:49 AM Moritz Mack ***@***.***> wrote: @reuvenlax <https://github.com/reuvenlax> JavaFieldSchema doesn't work for AWS models, the sdk v2 uses immutable objects based on builders / final fields. SdkPojo is the common interface of all of these models. — Reply to this email directly, view it on GitHub <#16947 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFAYJVKQRE7ZTS7RTWNVHJ3U5O7UFANCNFSM5PKC75YA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

mosche · 2022-02-28T19:04:32Z

Thanks, I'll have a closer look

mosche · 2022-03-02T11:02:41Z

@reuvenlax I had a closer look why JavaFieldSchema does not work. There's quite some issues, and this is by far not an exhaustive list:

Only public, non-static, non-transient fields are considered. Generated models in the AWS SDK are private, however. Using some kind of Field filter in JavaFieldSchema, that can then be overwritten, this could be addressed. But this obviously also means to generate different FieldValueGetter using ByteBuddy.
Next, more involved I suppose, such AWS SDK models contain final fields only, but there's no known creator. The annotation based approach isn't feasible for such "external" classes.
An annoyance, but has to be handled as well: These model classes may contain maps with non primitive types. This is not supported. Also, in some cases there might be recursive type hierarchies that can't be supported and have to be dealt with.

Also, I've seen all the optimisations done in JavaFieldSchema and JavaBeanSchema. Honestly, at this point I don't bother much about that yet. I'm more interested to understand what the right approach forward is giving all the AWS IOs currently use hand crafted low level coders.

mosche · 2022-03-02T11:17:48Z

Also, for context, here's a stripped down example how such a SdkPojo may look like:

public interface SdkPojo {
    List<SdkField<?>> sdkFields();
}

@Generated("software.amazon.awssdk:codegen")
public final class DeleteMessageRequest extends SqsRequest implements SdkPojo {
    private static final SdkField<String> QUEUE_URL_FIELD = SdkField.<String> builder(MarshallingType.STRING)
            .memberName("QueueUrl")
            .getter(DeleteMessageRequest::queueUrl)
            .setter(Builder::queueUrl)
            .build();

    private static final SdkField<String> RECEIPT_HANDLE_FIELD = SdkField.<String> builder(MarshallingType.STRING)
            .memberName("ReceiptHandle")
            .getter(DeleteMessageRequest::receiptHandle)
            .setter(Builder::receiptHandle)
            .build();

    private static final List<SdkField<?>> SDK_FIELDS = Collections.unmodifiableList(Arrays.asList(QUEUE_URL_FIELD,
            RECEIPT_HANDLE_FIELD));

    private final String queueUrl;

    private final String receiptHandle;

    private DeleteMessageRequest(BuilderImpl builder) {
        super(builder);
        this.queueUrl = builder.queueUrl;
        this.receiptHandle = builder.receiptHandle;
    }

    public final String queueUrl() {
        return queueUrl;
    }

    public final String receiptHandle() {
        return receiptHandle;
    }

    public static Builder builder() {
        return new BuilderImpl();
    }

    public final List<SdkField<?>> sdkFields() {
        return SDK_FIELDS;
    }

    public interface Builder extends SdkPojo {
        Builder queueUrl(String queueUrl);

        Builder receiptHandle(String receiptHandle);
    }

    static final class BuilderImpl implements Builder {
        private String queueUrl;

        private String receiptHandle;

        private BuilderImpl() {}

        public final Builder queueUrl(String queueUrl) {
            this.queueUrl = queueUrl;
            return this;
        }

        public final Builder receiptHandle(String receiptHandle) {
            this.receiptHandle = receiptHandle;
            return this;
        }

        public DeleteMessageRequest build() {
            return new DeleteMessageRequest(this);
        }

        public List<SdkField<?>> sdkFields() {
            return SDK_FIELDS;
        }
    }
}

reuvenlax · 2022-03-02T17:53:46Z

On Wed, Mar 2, 2022 at 3:02 AM Moritz Mack ***@***.***> wrote: @reuvenlax <https://github.com/reuvenlax> I had a closer look why JavaFieldSchema does not work. There's quite some issues, and this is by far not an exhaustive list: - Only public, non-static, non-transient fields <https://github.com/apache/beam/blob/master/sdks/java/core/src/main/java/org/apache/beam/sdk/schemas/utils/ReflectUtils.java#L129-L151> are considered. Generated models in the AWS SDK are private, however. Using some kind of Field filter in JavaFieldSchema, that can then be overwritten, this could be addressed. But this obviously also means to generate different FieldValueGetter using ByteBuddy. But the getter methods are public, right? - Next, more involved I suppose, such AWS SDK models contain final fields only, but there's no known creator. The annotation based approach isn't feasible for such "external" classes. That's something I think could be solved. Yes today we require an

annotation to specify the builder, however we could easily add a programmatic way to specify this.

- An annoyance, but has to be handled as well: These model classes may contain maps with non primitive types. This is not supported. Also, in some cases there might be recursive type hierarchies that can't be supported and have to be dealt with. I think we do support this, or are you referring to the key type?

Recursive type hierarchies are also definitely support.

…

Also, I've seen all the optimisations done in JavaFieldSchema and JavaBeanSchema. Honestly, at this point I don't bother much about that yet. I'm more interested to understand what the right approach forward is giving all the AWS IOs currently use hand crafted low level coders. — Reply to this email directly, view it on GitHub <#16947 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFAYJVNIELMVNBKPM6QFDOTU55DFZANCNFSM5PKC75YA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

mosche · 2022-03-02T18:37:07Z

But the getter methods are public, right?

There's public getters of course, but not following the "getX" naming convention.

I've also looked briefly at just extending GetterBasedSchemaProvider, that works really well actually. The read part is rather trivial. The field metadata of each SDK model provides an easy way to read fields (without any reflection involved).

static class SdkFieldValueGetter<ObjectT, ValueT> implements FieldValueGetter<ObjectT, ValueT> {
    private final SdkField<ValueT> field;

    public SdkFieldValueGetter(SdkField<ValueT> field) {
      this.field = field;
    }

    @Override
    @Nullable
    public ValueT get(ObjectT object) {
      return field.getValueOrDefault(object);
    }

    @Override
    public String name() {
      return field.memberName();
    }
  }

Recursive type hierarchies are also definitely support.

Problem with recursive types is the immutable Schema. I'm not aware of any way to generate such a schema for a recursive hierarchy ... same problem exists for FieldValueTypeInformation.
Just verified it quickly, I get a stackoverflow as expected ... so recursive types are definitely not supported.

reuvenlax · 2022-03-02T18:40:51Z

Do you mean mutually recursive? We considered supporting this with schema, but the complexity was high and there didn't seem to be many good use cases.

…

On Wed, Mar 2, 2022 at 10:37 AM Moritz Mack ***@***.***> wrote: But the getter methods are public, right? There's public getters of course, but not following the "getX" naming convention. I've also looked briefly at just extending GetterBasedSchemaProvider, that works really well actually. The read part is rather trivial. The field metadata of each SDK model provides an easy way to read fields (without any reflection involved). static class SdkFieldValueGetter<ObjectT, ValueT> implements FieldValueGetter<ObjectT, ValueT> { private final SdkField<ValueT> field; public SdkFieldValueGetter(SdkField<ValueT> field) { this.field = field; } @OverRide @nullable public ValueT get(ObjectT object) { return field.getValueOrDefault(object); } @OverRide public String name() { return field.memberName(); } } Recursive type hierarchies are also definitely support. Problem with recursive types is the immutable Schema. I'm not aware of any way to generate such a schema for a recursive hierarchy ... same problem exists for FieldValueTypeInformation. Just verified it quickly, I get a stackoverflow as expected ... so recursive types are definitely not supported. — Reply to this email directly, view it on GitHub <#16947 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFAYJVIAMSNFPACIJDYOFVDU56YODANCNFSM5PKC75YA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

reuvenlax · 2022-03-02T18:54:53Z

Unfortunately if you truly need recursive or mutually-recursive types, Beam Schemas won't work today. We supported nested types, but not true recursion.

…

On Wed, Mar 2, 2022 at 10:40 AM Reuven Lax ***@***.***> wrote: Do you mean mutually recursive? We considered supporting this with schema, but the complexity was high and there didn't seem to be many good use cases. On Wed, Mar 2, 2022 at 10:37 AM Moritz Mack ***@***.***> wrote: > But the getter methods are public, right? > > There's public getters of course, but not following the "getX" naming > convention. > > I've also looked briefly at just extending GetterBasedSchemaProvider, > that works really well actually. The read part is rather trivial. The field > metadata of each SDK model provides an easy way to read fields (without any > reflection involved). > > static class SdkFieldValueGetter<ObjectT, ValueT> implements FieldValueGetter<ObjectT, ValueT> { > private final SdkField<ValueT> field; > > public SdkFieldValueGetter(SdkField<ValueT> field) { > this.field = field; > } > > @OverRide > @nullable > public ValueT get(ObjectT object) { > return field.getValueOrDefault(object); > } > > @OverRide > public String name() { > return field.memberName(); > } > } > > Recursive type hierarchies are also definitely support. > > Problem with recursive types is the immutable Schema. I'm not aware of > any way to generate such a schema for a recursive hierarchy ... same > problem exists for FieldValueTypeInformation. > Just verified it quickly, I get a stackoverflow as expected ... so > recursive types are definitely not supported. > > — > Reply to this email directly, view it on GitHub > <#16947 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AFAYJVIAMSNFPACIJDYOFVDU56YODANCNFSM5PKC75YA> > . > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. > > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

mosche · 2022-03-04T19:18:39Z

@reuvenlax Trying to implement this on the existing Schema providers, I kept running into various issues. Also RowWithGetters proved to be difficult for this use case.

I introduce a similar wrapper row delegating to an underlying object very similar to RowWithGetters and optimized things a bit. I would be very grateful for your feedback. Though no rush, I'm off for the next week anyways ...

sdks/java/io/amazon-web-services2/src/main/java/org/apache/beam/sdk/values/AwsPojoRow.java

TheNeuralBit

Hi @mosche thanks for this! I can help review, I have a few initial questions.

FYI @apilloud (relevant for schema proliferation), and @chamikaramj (could enable cross-language AWS IOs)

sdks/java/io/amazon-web-services2/src/main/java/org/apache/beam/sdk/values/AwsPojoRow.java

...amazon-web-services2/src/test/java/org/apache/beam/sdk/io/aws2/schemas/AwsPojoUtilsTest.java

TheNeuralBit · 2022-03-23T16:15:49Z

.../io/amazon-web-services2/src/main/java/org/apache/beam/sdk/io/aws2/sns/SnsResponseCoder.java

+/**
+ * Custom Coder for WrappedSnsResponse.
+ *
+ * @deprecated Coder of deprecated {@link SnsResponse}.


What is the deprecation plan? Should users be opting in to using the SchemaCoder based approach, or are we keeping these coders here so that they can opt-out of schemas and use these instead?

I was planning to turn on schema coders by default by removing all "legacy" CoderProviderRegistrars and instead adding the generalSchemaProviderRegistrar for all AWS models. Users can opt-out using schemas using the deprecated withCoder setting.

sdks/java/io/amazon-web-services2/src/main/java/org/apache/beam/sdk/values/package-info.java

aromanenko-dev · 2022-04-27T10:59:13Z

Ping. What is a state of this PR? What are the next steps?

mosche · 2022-04-27T12:18:23Z

This is blocked / waiting for #17172

TheNeuralBit · 2022-06-17T20:55:00Z

Hi @mosche does this need a rebase or anything now that #17172 is merged, or is it ready to review?

mosche · 2022-06-20T14:21:03Z

Just wrapping up some other work, then I'll pick this up again 👍 There's a bit of work to be done to rebase this onto master.
Thanks for checking in @TheNeuralBit .

mosche · 2022-06-27T11:01:30Z

@TheNeuralBit I've migrated this PR onto GetterBasedSchemaProvider and RowWithGetters to take advantage of changes in #17172.
I also decided to remove support for self-recursive AWS models (e.g. DynamoDB's AttributeValue) for this initial version. Supporting that is a bit problematic with Beam schemas. In such a case a "traditional" coder is still required.

TheNeuralBit · 2022-07-08T17:16:48Z

retest this please

TheNeuralBit

I have a few high-level comments and nits, this looks good overall. I haven't been able to look at the implementation closely though and probably won't be able to before I leave for vacation at the end of today. If you'd like to keep making progress on this while I'm gone maybe @reuvenlax or @lukecwik could take a look.

...java/io/amazon-web-services2/src/main/java/org/apache/beam/sdk/io/aws2/coders/AwsCoders.java

TheNeuralBit · 2022-07-08T16:59:22Z

...mazon-web-services2/src/main/java/org/apache/beam/sdk/io/aws2/schemas/AwsSchemaProvider.java

+ *
+ * <p>Note: Beam doesn't support self-recursive schemas. Some AWS models, such as {@link
+ * software.amazon.awssdk.services.dynamodb.model.AttributeValue} are self-recursive and cannot be
+ * used with this schema provider.


Do we recommend continuing to use AwsCoders for this case?

It could also be helpful to link to the issue tracking recursive schemas.

nit: I'd say either "recursive" or "self-referential" instead of "self-recursive"

I've changed to self-referential 👍 DynamoDB AttributeValue is the only self-referential type I'm aware of and has a dedicated coder independent of AwsCoders.

The lack of support of self-referential types in Beam was apparently by design, so there's no such issue. My initial idea for AWS was to "fake" it by just skipping over self-referential fields at some depth. But that is obviously not correct and potentially dangerous as it might silently ignore some data.

...mazon-web-services2/src/main/java/org/apache/beam/sdk/io/aws2/schemas/AwsSchemaProvider.java

TheNeuralBit · 2022-07-08T17:03:07Z

...java/io/amazon-web-services2/src/main/java/org/apache/beam/sdk/io/aws2/sqs/MessageCoder.java

-import software.amazon.awssdk.services.sqs.model.Message;
-
-/** Custom Coder for handling SendMessageRequest for using in Write. */
-public class MessageCoder extends AtomicCoder<Message> implements Serializable {


This is public and not @Internal so technically we shouldn't just remove it outright. That being said this and SendMessageRequestCoder, MessageCoder are pretty clearly internal coders for use in their respective IOs, so it's probably fine.

I'll leave it up to you - if you want you could mark these coders deprecated and schedule them for removal in a later release.

You're absolutely right pointing this out 👍 Considering MessageCoder.of() / SendMessageRequestCoder.of() are both package private I think direct removal is justifiable in this case.

TheNeuralBit · 2022-07-08T17:19:49Z

...java/io/amazon-web-services2/src/main/java/org/apache/beam/sdk/io/aws2/schemas/AwsTypes.java

+  }
+
+  private static byte[] toBytes(Object sdkBytes) {
+    return ((SdkBytes) sdkBytes).asByteArrayUnsafe(); // TODO copy or use unsafe?


Are these TODOs something we can address now, or should there be an issue tracking it?

I had a look at what GetterBasedSchemaProvider does for byte[] / ByteBuffer. It's exposing the mutable bytes as well, so I'll keep the unsafe operations here. 👍

sdks/java/io/amazon-web-services2/src/main/java/org/apache/beam/sdk/io/aws2/sns/SnsIO.java

TheNeuralBit · 2022-07-08T17:23:08Z

sdks/java/io/amazon-web-services2/src/main/java/org/apache/beam/sdk/io/aws2/sns/SnsIO.java

     * sdkHttpMetadata with the HTTP response headers.
+     *
+     * @deprecated Writes fail fast in case of errors, no need to check headers.


Is this a change in behavior that we need to communicate to users?

Will these functions be removed later?

This is just a clarification why there's no need for a coder that includes HTTP response metadata, there's no change in behavior.
Plans is to remove these after a few releases.

sdks/java/io/amazon-web-services2/src/main/java/org/apache/beam/sdk/io/aws2/sns/SnsIO.java

TheNeuralBit · 2022-07-08T17:41:36Z

...n-web-services2/src/test/java/org/apache/beam/sdk/io/aws2/schemas/AwsSchemaProviderTest.java

+    return str.getBytes(UTF_8);
+  }
+
+  private <T> Condition<Row> field(String name, T value) {


This is handy, maybe it should be in SchemaTestUtils for discoverability?

This code depends on assertj-core and probably doesn't fit into SchemaTestUtils for that reason.
I could rewrite it as Matcher if you think it's worth it,e.g.:

public static Matcher<Row> containsFieldValues(Map<String, Object> expectedFieldValues)

TheNeuralBit · 2022-07-08T17:43:25Z

...n-web-services2/src/test/java/org/apache/beam/sdk/io/aws2/schemas/AwsSchemaProviderTest.java

+import software.amazon.awssdk.services.sqs.model.MessageAttributeValue;
+import software.amazon.awssdk.services.sqs.model.SendMessageRequest;
+
+public class AwsSchemaProviderTest {


Does this exercise all the types in the mapping from AwsTypes?

In fact not, thanks for checking ... I'll make sure to add more test cases to cover everything.

TheNeuralBit · 2022-07-08T17:48:07Z

retest this please

TheNeuralBit · 2022-07-08T17:48:59Z

Running tests to get a run of the newly forked integration tests (Java_Amazon-Web-Services2_IO_Direct)

mosche · 2022-07-12T11:26:25Z

Thanks a lot for your review @TheNeuralBit 🙏
Enjoy your time off!

…ow level coders

mosche · 2022-09-05T13:19:48Z

@TheNeuralBit Could you take a final look, I just rebased to account for the byte buddy changes on master ...

mosche · 2022-09-19T12:16:37Z

@TheNeuralBit Kind ping, are you ok merging this?

TheNeuralBit

LGTM, thank you!

You might consider creating an issue for removing the deprecated functionality, and linking it to a future release milestone. That will help us remember to actually remove it.

TheNeuralBit · 2022-09-19T19:30:49Z

Sorry for the delay

mosche · 2022-09-21T08:31:47Z

Thanks a lot @TheNeuralBit :)

github-actions bot added aws io java labels Feb 25, 2022

mosche force-pushed the BEAM-13416-AwsSchemas branch from 2f09257 to fb0f27f Compare March 4, 2022 19:12

mosche changed the title ~~[BEAM-13416] WIP~~ [BEAM-13416] Introduce Schema provider for AWS model classes extending SdkPojo Mar 4, 2022

mosche commented Mar 14, 2022

View reviewed changes

sdks/java/io/amazon-web-services2/src/main/java/org/apache/beam/sdk/values/AwsPojoRow.java Outdated Show resolved Hide resolved

mosche force-pushed the BEAM-13416-AwsSchemas branch from fb0f27f to c0790f6 Compare March 15, 2022 09:54

TheNeuralBit self-requested a review March 21, 2022 15:43

TheNeuralBit reviewed Mar 23, 2022

View reviewed changes

mosche mentioned this pull request Apr 12, 2022

[BEAM-14166] Performance improvements for RowWithGetter #17172

Merged

4 tasks

mosche force-pushed the BEAM-13416-AwsSchemas branch from c0790f6 to 2c189b1 Compare June 24, 2022 16:06

TheNeuralBit reviewed Jul 8, 2022

View reviewed changes

[BEAM-13416] Introduce Schema provider for AWS models and deprecate l…

38d9641

…ow level coders

mosche force-pushed the BEAM-13416-AwsSchemas branch from 2a95375 to 38d9641 Compare September 5, 2022 12:55

TheNeuralBit approved these changes Sep 19, 2022

View reviewed changes

TheNeuralBit merged commit 98589f2 into apache:master Sep 19, 2022

mosche mentioned this pull request Sep 21, 2022

[Task]: Remove deprecations for AWS coders and related #23315

Closed

mosche deleted the BEAM-13416-AwsSchemas branch September 21, 2022 08:31

mosche mentioned this pull request May 16, 2023

Remove deprecated AWS coders #26715

Merged

3 tasks

[BEAM-13416] Introduce Schema provider for AWS model classes extending SdkPojo #16947

[BEAM-13416] Introduce Schema provider for AWS model classes extending SdkPojo #16947

Conversation

mosche commented Feb 25, 2022 • edited Loading

GitHub Actions Tests Status (on master branch)

mosche commented Feb 25, 2022

aromanenko-dev commented Feb 28, 2022

reuvenlax commented Feb 28, 2022

mosche commented Feb 28, 2022

mosche commented Feb 28, 2022

reuvenlax commented Feb 28, 2022 via email

mosche commented Feb 28, 2022

mosche commented Mar 2, 2022

mosche commented Mar 2, 2022

reuvenlax commented Mar 2, 2022 via email

mosche commented Mar 2, 2022

reuvenlax commented Mar 2, 2022 via email

reuvenlax commented Mar 2, 2022 via email

mosche commented Mar 4, 2022

TheNeuralBit left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aromanenko-dev commented Apr 27, 2022

mosche commented Apr 27, 2022

TheNeuralBit commented Jun 17, 2022

mosche commented Jun 20, 2022

mosche commented Jun 27, 2022

TheNeuralBit commented Jul 8, 2022

TheNeuralBit left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TheNeuralBit commented Jul 8, 2022

TheNeuralBit commented Jul 8, 2022

mosche commented Jul 12, 2022

mosche commented Sep 5, 2022

mosche commented Sep 19, 2022

TheNeuralBit left a comment

Choose a reason for hiding this comment

TheNeuralBit commented Sep 19, 2022

mosche commented Sep 21, 2022

mosche commented Feb 25, 2022 •

edited

Loading