[BEAM-14020] Adding SchemaTransform, SchemaTransformProvider, TypedSchemaTransformProvider, and PCollectionRowTuple

[laraschmidt]

Adding SchemaTransform, SchemaTransformProvider, and PCollectionRowTuple. This is an interface which allows for Schema-aware transforms and will eventually replace SchemaIO.
R:@TheNeuralBit

Doc: https://s.apache.org/beam-schema-transform

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.

[laraschmidt]

Run Java PreCommit

[TheNeuralBit]

nit: looks like you need to s/PCollectionTuple/PCollectionRowTuple/

It's too bad there's so much duplication from PCollectionTuple, but I can't think of a way to structure this that avoids it. Maybe @kennknowles
has an idea (but I know he dislikes inheritance, so maybe he prefers it this way :P)

[laraschmidt]

Yeah I wanted that too, it seems like it should be easy to do. But I think unless we template the underlying class there's no real way to make this work. We could maybe make PCollectionTupleBase and then Have PCollectionTuple extends Object and PCollectionRowTuple extend Row. But then we'd end up with Object instead of ?. I'm not actually sure how well that would work. Could give it a try but it still seems kind of messy.

[TheNeuralBit]

LGTM, just one minor nit. Thank you!

[TheNeuralBit]

Run Java PreCommit

[TheNeuralBit]

It looks like this is causing an actual failure in Java PreCommit:

java.lang.IllegalStateException: Pipeline update will not be possible because the following transforms do not have stable unique names: Create.Values.

Conflicting instances:
- name=Create.Values:
    - Create.Values
    - Create.Values

You can fix it adding a name when you call apply(): pipeline.apply(<name>, <transform>).
	at org.apache.beam.sdk.Pipeline.validate(Pipeline.java:619)
	at org.apache.beam.sdk.Pipeline.run(Pipeline.java:322)
	at org.apache.beam.sdk.testing.TestPipeline.run(TestPipeline.java:399)
	at org.apache.beam.sdk.testing.TestPipeline.run(TestPipeline.java:335)
	at org.apache.beam.sdk.values.PCollectionRowTupleTest.testComposePCollectionRowTuple(PCollectionRowTupleTest.java:101)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)

[TheNeuralBit]

Run Java_Examples_Dataflow PreCommit

[laraschmidt]

Run Java_Examples_Dataflow PreCommit

[TheNeuralBit]

Run Java PreCommit

[laraschmidt]

Run Java PreCommit

[TheNeuralBit]

checkstyle is failing in Java PreCommit now, it wants these to be ALL_CAPS