Re: Beam Slack channel

Thanks... and joined already! :) /G. On Fri, Jul 28, 2017 at 12:50 PM, James wrote: > Invite Sent. > > Guillermo Rodríguez Cano 于2017年7月28日周五 下午6:42写道： > > > Hello, > > > > as the subject hints... new here. Can someone add me to the Slack >

Beam Slack channel

Hello, as the subject hints... new here. Can someone add me to the Slack channel, please? /G.

Re: Beam Slack channel

Invite Sent. Guillermo Rodríguez Cano 于2017年7月28日周五 下午6:42写道： > Hello, > > as the subject hints... new here. Can someone add me to the Slack channel, > please? > > /G. >

Build failed in Jenkins: beam_Release_NightlySnapshot #490

See Changes: [iemejia] [BEAM-1984] Fix scope for dependencies needed only for test purposes [kirpichov] Fixes BigQueryIO.Write javadoc for to(ValueInSingleWindow) [kirpichov] [BEAM-2640] Introduces

Re: Style of messages for checkArgument/checkNotNull in IOs

On Fri, Jul 28, 2017 at 11:21 AM, Thomas Groh wrote: > I'm in favor of the wording in the style of the first: it's an immediately > actionable message that will have an associated stack trace, but will > provide the parameter in plaintext so the caller doesn't have to

Re: Style of messages for checkArgument/checkNotNull in IOs

As to the choice of check method: - checkArgument throws an InvalidArgumentException, which is clearly in "your fault" category, a la HTTP 4xx - checkNotNull throws an NPE, which is usually a "my fault" exception, a la HTTP 5xx. The docs on NPE are not clear on blame, and this is a bug in the

Re: Style of messages for checkArgument/checkNotNull in IOs

Hi I'm a bit concerned because it has been discussed in a Jira and we discussed especially about this with Kenn and I. It dates from the incubation period. I changes most of the IOs I did for style 2 whereas I started with style 1. I'm ready to change again on the IOs but we agreed that

Re: Style of messages for checkArgument/checkNotNull in IOs

So here's an easy solution: our own checkNotNull that throws InvalidArgumentException with a good error message. The error message can then be templated to allow terse invocations with just the method and parameter. Unsure why I didn't go for this straightaway. On Fri, Jul 28, 2017 at 11:43 AM,

Re: Style of messages for checkArgument/checkNotNull in IOs

Agree Regards JB On Jul 28, 2017, 20:22, at 20:22, Thomas Groh wrote: >I'm in favor of the wording in the style of the first: it's an >immediately >actionable message that will have an associated stack trace, but will >provide the parameter in plaintext so the caller

Style of messages for checkArgument/checkNotNull in IOs

Hey all, I think this has been discussed before on a JIRA issue but I can't find it, so raising again on the mailing list. Various IO (and non-IO) transforms validate their builder parameters using Preconditions.checkArgument/checkNotNull, and use different styles for error messages. There are 2

Re: Style of messages for checkArgument/checkNotNull in IOs

I'm in favor of the wording in the style of the first: it's an immediately actionable message that will have an associated stack trace, but will provide the parameter in plaintext so the caller doesn't have to dig through the invoked code, they can just look at the documentation. I've recently

Re: Style of messages for checkArgument/checkNotNull in IOs

Okay, so then let's change guidance to: - Always use checkArgument to check stuff that the user supplied - Use style 1 for messages on the checkArgument ? On Fri, Jul 28, 2017 at 11:31 AM Jean-Baptiste Onofré wrote: > Agree > > Regards > JB > > On Jul 28, 2017, 20:22, at

Re: Style of messages for checkArgument/checkNotNull in IOs

(I don't think changing messages in existing IOs is a high priority, btw - just a nice-to-have, as long as we have guidance for future IOs) On Fri, Jul 28, 2017 at 11:37 AM Eugene Kirpichov wrote: > Okay, so then let's change guidance to: > - Always use checkArgument to

Re: Style of messages for checkArgument/checkNotNull in IOs

Yuck. I think that checkNotNull throwing a NPE is a very poor design choice from the author of checkNotNull. On Fri, Jul 28, 2017 at 11:29 AM, Kenneth Knowles wrote: > As to the choice of check method: > > - checkArgument throws an InvalidArgumentException, which is

Re: Dynamic file-based sinks

The AvroIO PR is now merged, so you can write to different destinations based on the value. It's available in head, and will be in Beam 2.2.0. On Wed, Jul 26, 2017 at 10:00 AM, Reuven Lax wrote: > Yes, there was! TextIO support is already merged into Beam (it missed the > 2.1