My opinion regarding the execution side and symmetry is this: it was always
wrong to use the term "PTransform" to describe the thing that is executed
by workers or SDK harnesses. They aren't the same and shouldn't be thought
of or implemented as the same.
The original Dataflow runner had it right
+1
While the current Go SDK has always been portability first it was designed
with a goal of enabling it to back out of that at the time, so it's fully
on a broad vertical slice of things to translate to protos and back again,
leading to difficulties when adding a new core transform.
I have an
On Wed, Feb 14, 2024 at 10:28 AM Kenneth Knowles wrote:
>
> Hi all,
>
> TL;DR I want to add some API like PTransform.getURN, toProto and fromProto,
> etc. to the Java SDK. I want to do this so that making a PTransform support
> portability is a natural part of writing the transform and not a
On Wed, Feb 14, 2024 at 10:28 AM Kenneth Knowles wrote:
> Hi all,
>
> TL;DR I want to add some API like PTransform.getURN, toProto and
> fromProto, etc. to the Java SDK. I want to do this so that making a
> PTransform support portability is a natural part of writing the transform
> and not a
Hi all,
TL;DR I want to add some API like PTransform.getURN, toProto and fromProto,
etc. to the Java SDK. I want to do this so that making a PTransform support
portability is a natural part of writing the transform and not a totally
separate thing with tons of boilerplate.
What do you think?
I
