Re: Follow up ideas, to simplify creating MonitoringInfos.

I was unable to get this to compile and could find no examples of this on the proto github. Would it be helpful to post the compiler output? -Max On 31.10.18 19:19, Lukasz Cwik wrote: I see and don't know how to help you beyond what your already suggesting. From what I remember, maps were

Re: Follow up ideas, to simplify creating MonitoringInfos.

I see and don't know how to help you beyond what your already suggesting. >From what I remember, maps were added as syntactic sugar of lists of key value pairs. On Tue, Oct 30, 2018 at 5:37 PM Alex Amato wrote: > I am not sure on the correct syntax to populate the instances of my >

Re: Follow up ideas, to simplify creating MonitoringInfos.

I am not sure on the correct syntax to populate the instances of my MonitoringInfoSpec messages message MonitoringInfoSpec { string urn = 1; string type_urn = 2; repeated string required_labels = 3; * map annotations = 4;* } Notice how the annotations field is not used anywhere. I was

Re: Follow up ideas, to simplify creating MonitoringInfos.

I'm not sure what you mean by "Using a map in an option." For your second issue, the google docs around this show[1]: Note that if you want to use a custom option in a package other than the one in which it was defined, you must prefix the option name with the package name, just as you would for

Re: Follow up ideas, to simplify creating MonitoringInfos.

Hi Robert and community, :) I was starting to code this up, but I wasn't sure exactly how to do some of the proto syntax. Would you mind taking a look at this doc and let me know if you know how to

Re: Follow up ideas, to simplify creating MonitoringInfos.

Okay. That makes sense. Using runtime validation and protos is what I was thinking as well. I'll include you as a reviewer in my PRs. As for the choice of a builder/constructor/factory. If we go with factory methods/constructor then we will need a method for each metric type (intCounter,

Re: Follow up ideas, to simplify creating MonitoringInfos.

Thanks for bringing this to the list; it's a good question. I think the difficulty comes from trying to statically define a lists of possibilities that should instead be runtime values. E.g. we currently we're up to about a dozen distinct types, and having a setter for each is both verbose and

Re: Follow up ideas, to simplify creating MonitoringInfos.

FWIW AutoValue will build most of that class for you, if it is as you say. Kenn On Tue, Oct 23, 2018 at 6:04 PM Alex Amato wrote: > Hi Robert + beam dev list, > > I was thinking about your feedback in PR#6205 > , and agree that this >

Follow up ideas, to simplify creating MonitoringInfos.

Hi Robert + beam dev list, I was thinking about your feedback in PR#6205 , and agree that this monitoring_infos.py https://github.com/apache/beam/blob/61a9f7193f1a61869915da3b4f386b34eac63822/sdks/python/apache_beam/metrics/monitoring_infos.py> became a