On Fri, Oct 18, 2019 at 2:36 PM Luke Cwik wrote:
>
> Robert it seems like your for Plan A. Assuming we go forward with nanosecond
> and based upon your analysis in 3), wouldn't that mean we would have to make
> a breaking change to the Java SDK to swap to nanosecond precision?
Yes. But regardle
There are some changes with Java where the system class loader is no longer
a URL class loader[1].
Also reflection is changing such that non-public fields/methods aren't
accessible which we (or our dependencies) may be doing. Not sure how our
usage of bytecode generation/proxies will need to chang
Robert it seems like your for Plan A. Assuming we go forward with
nanosecond and based upon your analysis in 3), wouldn't that mean we would
have to make a breaking change to the Java SDK to swap to nanosecond
precision?
On Fri, Oct 18, 2019 at 11:35 AM Robert Bradshaw
wrote:
> TL;DR: We should
TL;DR: We should just settle on nanosecond precision ubiquitously for
timestamp/windowing in Beam.
Re-visiting this discussion in light of cross-language transforms and
runners, and trying to tighten up testing. I've spent some more time
thinking about how we could make these operations granulari
Welcome & thanks!
On Fri, Oct 18, 2019 at 5:55 AM Ismaël Mejía wrote:
> Hello, you were added as a contributor. Please create and assign the
> ticket. Welcome!
>
> On Fri, Oct 18, 2019 at 7:05 AM Noah Goodrich wrote:
> >
> > Hi,
> >
> > My name is Noah Goodrich (username ngoodrich). I've recent
Cool. Thanks Lukasz!
-P.
On Fri, Oct 18, 2019 at 3:00 AM Łukasz Gajowy
wrote:
>
> I agree that jobs that timeout should be notified to builds@. Is there
>> any other source of data (e.g. dashboards) that gets tagged with that info?
>>
>
> AFAIK no - builds@ is the only place that gets notified a
Hi Theodore!
Display data is what's throwing the error, but the BigQuerySource does not
support value providers even despite that issue because it's a Dataflow
native source. Unfortunately, this is not currently possible.
Currently, you could do this executing a BQ export job (using a DoFn), and
us
Hi,
I'm experiencing errors in validates runner of flink (1.8) on current
master. The failure is
java.lang.AssertionError: processing bundle should have been called before
finish bundle
Expected: is
but: was
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
Additionally, for reference
https://stackoverflow.com/questions/46595149/dynamic-bigquery-query-in-dataflow-template
On Fri, Oct 18, 2019 at 9:34 AM Theodore Siu wrote:
> Hi,
>
> We are attempting to build a Dataflow template in Beam Python and are
> running into issues with using a value provid
Hi,
We are attempting to build a Dataflow template in Beam Python and are
running into issues with using a value provider specifically
with beam.io.BigQuerySource which throws the following error.ValueError:
Invalid DisplayDataItem. Value RuntimeValueProvider(option: input, type:
str, default_
Hi all,
I want to contribute more actively to this and push Beam as close as
currently possible towards Java11 both in terms of running and compiling
the project with it.
I needed a bigger picture so I created a spreadsheet to have a clear
roadmap for the whole process. It starts with testing exi
Hello, you were added as a contributor. Please create and assign the
ticket. Welcome!
On Fri, Oct 18, 2019 at 7:05 AM Noah Goodrich wrote:
>
> Hi,
>
> My name is Noah Goodrich (username ngoodrich). I've recently started using
> the Beam Python SDK. I've found a first issue with the BigQueryFileL
> I agree that jobs that timeout should be notified to builds@. Is there
> any other source of data (e.g. dashboards) that gets tagged with that info?
>
AFAIK no - builds@ is the only place that gets notified about failures (and
soon about timoeuts/aborts once the pr gets merged).
> I'm just thi
13 matches
Mail list logo