Re: Stability of Timer.withOutputTimestamp

2020-02-06 Thread Steve Niemitz
cool, thank you.  I meant stable as in "my pipeline will produce correct
results", API changes are fine with me.

Still curious too on the second question wrt firing time vs output time
validation.

On Wed, Feb 5, 2020 at 11:20 PM Kenneth Knowles  wrote:

> It is definitely too new to be stable in the sense of not even tiny
> changes to the API / runtime compatibility.
>
> However, in my opinion it is so fundamental (and overdue) it will
> certainly exist in some form.
>
> Feel free to use it if you are OK with the possibility of minor
> compile-time adjustments and you do not require Dataflow pipeline update
> compatibility.
>
> Kenn
>
> On Wed, Feb 5, 2020 at 10:31 AM Luke Cwik  wrote:
>
>> +Reuven Lax 
>>
>> On Wed, Feb 5, 2020 at 7:33 AM Steve Niemitz  wrote:
>>
>>> Also, as a follow up, I'm curious about this commit:
>>>
>>> https://github.com/apache/beam/commit/80862f2de6f224c3a1e7885d197d1ca952ec07e3
>>>
>>> My use case is that I want to set a timer to fire after the max
>>> timestamp of a window, but hold the watermark to the max timestamp until it
>>> fires, essentially delaying the window closing by some amount of event
>>> time.  Previous to that revert commit it seems like that would have been
>>> possible, but now it would fail (since the target is after the window's
>>> maxTimestamp).
>>>
>>> What was the reason this was reverted, and are there plans to un-revert
>>> it?
>>>
>>> On Wed, Feb 5, 2020 at 10:01 AM Steve Niemitz 
>>> wrote:
>>>
 I noticed that Timer.withOutputTimestamp has landed in 2.19, but I
 didn't see any mention of it in the release notes.

 Is this feature considered stable (specifically on dataflow)?

>>>


Re: Stability of Timer.withOutputTimestamp

2020-02-05 Thread Kenneth Knowles
It is definitely too new to be stable in the sense of not even tiny changes
to the API / runtime compatibility.

However, in my opinion it is so fundamental (and overdue) it will certainly
exist in some form.

Feel free to use it if you are OK with the possibility of minor
compile-time adjustments and you do not require Dataflow pipeline update
compatibility.

Kenn

On Wed, Feb 5, 2020 at 10:31 AM Luke Cwik  wrote:

> +Reuven Lax 
>
> On Wed, Feb 5, 2020 at 7:33 AM Steve Niemitz  wrote:
>
>> Also, as a follow up, I'm curious about this commit:
>>
>> https://github.com/apache/beam/commit/80862f2de6f224c3a1e7885d197d1ca952ec07e3
>>
>> My use case is that I want to set a timer to fire after the max timestamp
>> of a window, but hold the watermark to the max timestamp until it fires,
>> essentially delaying the window closing by some amount of event time.
>> Previous to that revert commit it seems like that would have been possible,
>> but now it would fail (since the target is after the window's maxTimestamp).
>>
>> What was the reason this was reverted, and are there plans to un-revert
>> it?
>>
>> On Wed, Feb 5, 2020 at 10:01 AM Steve Niemitz 
>> wrote:
>>
>>> I noticed that Timer.withOutputTimestamp has landed in 2.19, but I
>>> didn't see any mention of it in the release notes.
>>>
>>> Is this feature considered stable (specifically on dataflow)?
>>>
>>


Re: Stability of Timer.withOutputTimestamp

2020-02-05 Thread Luke Cwik
+Reuven Lax 

On Wed, Feb 5, 2020 at 7:33 AM Steve Niemitz  wrote:

> Also, as a follow up, I'm curious about this commit:
>
> https://github.com/apache/beam/commit/80862f2de6f224c3a1e7885d197d1ca952ec07e3
>
> My use case is that I want to set a timer to fire after the max timestamp
> of a window, but hold the watermark to the max timestamp until it fires,
> essentially delaying the window closing by some amount of event time.
> Previous to that revert commit it seems like that would have been possible,
> but now it would fail (since the target is after the window's maxTimestamp).
>
> What was the reason this was reverted, and are there plans to un-revert it?
>
> On Wed, Feb 5, 2020 at 10:01 AM Steve Niemitz  wrote:
>
>> I noticed that Timer.withOutputTimestamp has landed in 2.19, but I didn't
>> see any mention of it in the release notes.
>>
>> Is this feature considered stable (specifically on dataflow)?
>>
>


Re: Stability of Timer.withOutputTimestamp

2020-02-05 Thread Steve Niemitz
Also, as a follow up, I'm curious about this commit:
https://github.com/apache/beam/commit/80862f2de6f224c3a1e7885d197d1ca952ec07e3

My use case is that I want to set a timer to fire after the max timestamp
of a window, but hold the watermark to the max timestamp until it fires,
essentially delaying the window closing by some amount of event time.
Previous to that revert commit it seems like that would have been possible,
but now it would fail (since the target is after the window's maxTimestamp).

What was the reason this was reverted, and are there plans to un-revert it?

On Wed, Feb 5, 2020 at 10:01 AM Steve Niemitz  wrote:

> I noticed that Timer.withOutputTimestamp has landed in 2.19, but I didn't
> see any mention of it in the release notes.
>
> Is this feature considered stable (specifically on dataflow)?
>


Stability of Timer.withOutputTimestamp

2020-02-05 Thread Steve Niemitz
I noticed that Timer.withOutputTimestamp has landed in 2.19, but I didn't
see any mention of it in the release notes.

Is this feature considered stable (specifically on dataflow)?