The customer also contacted me directly, but for future explorers, I'll relay what I told them.
The Go SDK chose *not* to encourage the per-PCollection overriding of coders, compared to Java and Python where they seem required. Coders are commonly set *per type*, and the same one used throughout the pipeline for all instances of that type. That would be using `beam.RegisterCoder` https://github.com/apache/beam/blob/master/sdks/go/pkg/beam/forward.go#L131. Generally, one registers the element type, with a stateless encoder and decoder function. It's much easier and cheaper to make new types in Go, so if using the same coder throughout the pipeline is undesirable, here's how I would do it. Make an identical, assignable type (`type NewType OldType`), and register a coder for it. Then when you do need the additional encoding behavior, besure to emit elements of NewType, which should be possible as OldType would be assignable to NewType. For that reason, it's unfortunate there's a vestigial "SetCoder" method on the Go SDK's PCollection type, since that pre-dated the coder infrastructure, and was never cleaned up. Tightly coupling the type to coder was a choice that's a bit hard to extract from the current SDK however. Robert Burke On 2024/10/08 16:21:41 Ahmet Altay via user wrote: > (Asking a question on a user's behalf, question is in the title.) > > Ahmet >
