On Tue, Jun 11, 2019 at 8:04 PM Kenneth Knowles <k...@apache.org> wrote:
> > I believe the schema registry is a transient construction-time concept. I > don't think there's any need for a concept of a registry in the portable > representation. > > I'd rather urn:beam:schema:logicaltype:javasdk not be used whenever one >> has (say) a Java POJO as that would prevent other SDKs from "understanding" >> it as above (unless we had a way of declaring it as "just an >> alias/wrapper"). >> > > I didn't understand the example I snipped, but I think I understand your > concern here. Is this what you want? (a) something presented as a POJO in > Java (b) encoded to a row, but still decoded to the POJO and (c) non-Java > SDK knows that it is "just a struct" so it is safe to mess about with or > even create new ones. If this is what you want it seems potentially useful, > but also easy to live without. This can also be done entirely within the > Java SDK via conversions, leaving no logical type in the portable pipeline. > I'm imaging a world where someone defines a PTransform that takes a POJO for a constructor, and consumes and produces a POJO, and is now usable from Go with no additional work on the PTransform author's part. But maybe I'm thinking about this wrong and the POJO <-> Row conversion is part of the @ProcesssElement magic, not encoded in the schema itself.