Re: What next for streaming SQL?

Sliding windows are so different from tumbling windows that it doesn’t make sense to give them a “window key”. With sliding windows, every row has its own window. So, given a row R you determine what rows are in R’s window based on its windowing criteria, e.g. “rows between 5 preceding and 5 fol

Re: What next for streaming SQL?

Hi, Julian, Great! I am looking forward to it. Could you help to answer my question regarding to the sliding windows in the previous email? Thanks a lot! -Yi On Tue, May 5, 2015 at 10:46 AM, Julian Hyde wrote: > > On May 4, 2015, at 10:52 AM, Yi Pan wrote: > > > Just one observation that I w

Re: What next for streaming SQL?

On May 4, 2015, at 10:52 AM, Yi Pan wrote: > Just one observation that I wanted to add in: I noted that actually any > range-based query clause on an ordered stream essentially means the need > for a windowing method in the ordered stream scan. Is it possible to > identify a common syntax expres

Re: What next for streaming SQL?

Just one observation that I wanted to add in: I noted that actually any range-based query clause on an ordered stream essentially means the need for a windowing method in the ordered stream scan. Is it possible to identify a common syntax expression from the query parser in Calcite for any range-ba

Re: What next for streaming SQL?

Hi, Julian, Thanks for the reply. I want to add a few more points here: {quote} Once you have computed that boundary and stored it in your data structure you can keep on adding rows until you see one rowtime 11:00:00 or higher. {quote} The above is not true when the incoming messages in the real

Re: What next for streaming SQL?

When I implemented this in the past, I found out that what I needed was not the window size exactly, but the next boundary value. For example, if I am using FLOOR(rowtime TO HOUR) and the current row is 10:03:00 then the next boundary will be 11:00:00. Once you have computed that boundary and st

Re: What next for streaming SQL?

Hi Julian, You are correct, I was referring to https://github.com/apache/incubator-calcite/blob/master/doc/STREAM.md#tumbling-windows. What I meant by "tumbling window size" was size of the window by seconds, minutes or hours. Its possible to deduce the size for an expression like "FLOOR(rowtime T

Re: What next for streaming SQL?

Can you give an example of the SQL syntax you are using for tumbling windows? Does it use GROUP BY and FLOOR, as in https://github.com/apache/incubator-calcite/blob/master/doc/STREAM.md#tumbling-windows ? W

Re: What next for streaming SQL?

Hi Julian, I am working on tumbling windows and hoping to have a look at other types of window aggregates next. I was trying to extract the window spec out from the aggregate operator (for tumbling window) and figure out that its impossible to infer tumbling window size from date time expressions

What next for streaming SQL?

Milinda, I have seen your work adding initial streaming SQL to Samza. Good stuff. Which types of query are you thinking of doing next? As of calcite-1.2, the streaming extensions are in Calcite’s master branch. (See https://github.com/apache/incubator-calcite/blob/master/doc/STREAM.md.) We are