Hi Shuyi,
Congratulations for becoming a Calcite committer and thank you for all the
contributions to Calcite (and Flink)!
Best,
Fabian
2018-04-04 1:18 GMT+02:00 Michael Mior :
> If you ever see any opportunity to speak about Calcite, you're always
> welcome to do so. If you ask on the list, th
Hi everyone,
I'd like to share the plans for MATCH_RECOGNIZE support in Flink.
Flink features a so-called CEP library for quite some time [1]. The CEP
features is a popular feature and frequently used.
In a nutshell, the library provides a domain-specific API to define event
patterns. The pattern
> julianhyde/calcite/commit/ee460847643ec17544f310088affd99be4028bb6> that
> could be extended.
>
> Julian
>
>
> > On Jul 31, 2018, at 8:07 AM, Fabian Hueske wrote:
> >
> > Hi everyone,
> >
> > I'd like to share the plans for MATCH_RECOGNIZE support in
s to terminate (i.e. can’t handle streaming queries). So, if Flink
> SQL is were able to run queries on an EMP table, then I think it could be
> tested using Quidem.
>
> > On Aug 2, 2018, at 6:27 AM, Fabian Hueske wrote:
> >
> > Hi Julian,
> >
> > It would be gr
atement that can describe itself and execute a query.
> Quidem makes light use of JDBC.
>
> > On Aug 6, 2018, at 10:33 AM, Fabian Hueske wrote:
> >
> > OK, I see.
> > Flink doesn't have support for JDBC yet.
> > Would need to look into that.
> >
> >
Hi everybody,
First of all, thanks Julian for reaching out to us and Jesus for offering
your help.
I am excited that the Flink community is finally starting to add SQL
support for batch data sets and data streams to Flink.
I believe Calcite will serve as an excellent component in our architecture.
Hi,
I am using Calcite's RelBuilder to directly generate Calcite RelNodes from
Flink Table API calls [1].
The translations works very well and was pretty straightforward to
implement, however it looks like the RelBuilder does not thoroughly
validate the generated expressions.
It ensures that field
eChecker;
>
> There isn’t a SqlValidator accessible to RelBuilder, but I think we can
> somehow make RelBuilder call into the policies.
>
> Julian
>
>
>
> > On Feb 1, 2016, at 3:13 PM, Fabian Hueske wrote:
> >
> > Hi,
> >
> > I am using Calcite&#x
Hi,
first of all, thanks for starting this discussion. As Stephan said before,
the Flink community is working towards support for SQL on streams. IMO, it
would be very nice if the different efforts for SQL on streams could
converge towards a core set of semantics and syntax.
I read the proposal o
Excellent! I missed the punctuations in the todo list.
What kind of strategies do you have in mind to handle events that arrive
too late? I see
1. dropping of late events
2. computing an updated window result for each late arriving
element (implies that the window state is stored for a certain per
e Q with a latency of
> 15 ms”: the system may not be able to achieve it.
>
> In summary: I would allow latency and late-row-handling and other QoS
> annotations in the query but it’s not the most natural or powerful place to
> put them.
>
> Julian
>
>
> > On Feb 6, 2
Hi Cody,
the monotone (or quasi-monotone) attribute required for grouping a stream
in Calcite is a generalization of the timestamp/watermark concept in Flink.
The timestamps in Flink are quasi-monotone, i.e., they are increasing but
might be slightly out of order. This out-of-orderness is controll
Hi Radu,
sliding windows as described by Julian will emit exactly one row for each
incoming row.
In the scenario you describe only one row will be emitted when ordN6
arrives (otherwise, each input row would result in five emitted rows).
So sliding windows seem to be what you are looking for.
Bes
e ROWS
> 5 PRECEDING)
>FROM Orders
>GROUP BY order_type
>
>
> I am asking this from the perspective of knowing if this would enable to
> implement this over KeyedStream(s) such as the ones in Flink + the windows
>
>
>
> -Original Message-
> From:
Hi everybody,
I second Tyler: thanks for this write-up, Julian, and sorry for not
responding earlier to this thread.
After Flink Forward, a few folks and I started to draft a proposal for
Flink's StreamSQL semantics.
I wanted to finalize our proposal (just shared it on the Flink dev list)
before r
Hi Julian,
thanks a lot for your thoughts and advice!
I'd like to give a bit more background on why we were thinking about system
attributes and why we did not want to allow changing the time attribute.
In Flink, the event-time attribute is handled as meta data of each record.
Users do not have
Hi Tyler,
thanks for pushing this effort and including the Flink list.
I haven't managed to read the doc yet, but just wanted to thank you for the
write-up and let you know that I'm very interested in this discussion.
We are very close to the feature freeze of Flink 1.3 and I'm quite busy
getting
-Tyler
>
>
> On Wed, Apr 26, 2017 at 8:18 AM Tyler Akidau wrote:
>
> > No worries, thanks for the heads up. Good luck wrapping all that stuff
> up.
> >
> > -Tyler
> >
> > On Tue, Apr 25, 2017 at 12:07 AM Fabian Hueske
> wrote:
> >
> >&
2017-05-11 7:14 GMT+02:00 Tyler Akidau :
> On Tue, May 9, 2017 at 3:06 PM Fabian Hueske wrote:
>
> > Hi Tyler,
> >
> > thank you very much for this excellent write-up and the super nice
> > visualizations!
> > You are discussing a lot of the things that we ha
Thanks Julian. I agree, semantically TUMBLE_START would work.
Unfortunately, the window implementations of Flink's DataStream API (which
are used to implement TUMBLE, HOP, and SESSION windows) assign (window_end
- 1) as internal timestamp to records. The reason for this design decision
is that oth
Thanks for the great write up!
I think this s very good starting point for a detailed discussion about
features, syntax and semantics of streaming SQL.
I'll comment on the document in the next days and describe Flink's current
status, our approaches (or planned approaches) and ask a couple of
ques
y well written
> and organized.
> I like the most part. The major concern I have is about the "explicit
> trigger". I left a few comments towards this and would like to know what
> the others think about it.
>
> Regards,
> Shaoxuan
>
> On Sun, Jul 30, 2017 at 4:43 PM,
Thanks for the quick reply, Julian.
It's great that the first issue is already fixed in 1.14!
Regarding the second issue.
The problem with the logical plan that Xingcan posted is not the handling
of outer rows for which the right side is empty.
Our concern is that the outer join predicate is push
ate doesn’t give the
> right behavior. Can you log a bug?
>
> I’d rather not add filters to the Correlate operator unless absolutely
> necessary. In this case, is it sufficient to apply the Filter to the right
> input of the Correlate?
>
> Julian
>
>
> > On Oct 4, 20
pty(e) then {($0, $1, null)} else
> map(e, e -> ($0, $1, e.name)) end end)
> Scan(dept)
>
> Julian
>
> [1] https://issues.apache.org/jira/browse/CALCITE-1472 <
> https://issues.apache.org/jira/browse/CALCITE-1472>
>
> [2] https://dzone.com/articles/selectmany-pr
Congrats Christian!
Best, Fabian
2017-10-11 20:11 GMT+02:00 Julian Hyde :
> On behalf of the PMC I am delighted to announce Christian Beikov as a new
> Calcite committer.
>
> Christian’s first contribution[1] — quite out the blue — was a new adapter
> for Elasticsearch5. Since then he has made v
Hi Xingcan,
you could restrict the rule that translates the join operator by adding a
condition that checks if the join condition contains an equality predicate
on expressions that do not access a field (i.e., expressions that compute a
value).
This would prevent such plans from being translated a
Congratulations!
2017-11-16 0:13 GMT+01:00 Aman Sinha :
> Congratulations Michael !
>
> On Wed, Nov 15, 2017 at 12:05 PM, Julian Hyde wrote:
>
> > Another year, another peaceful transition of power, another talented
> chair
> > with unique skills and perspectives. Well done, Calcite project!
> >
Fabian Hueske created CALCITE-1997:
--
Summary: VolcanoPlanner.validate() causes NPE due to root == null
on DEBUG log level
Key: CALCITE-1997
URL: https://issues.apache.org/jira/browse/CALCITE-1997
Fabian Hueske created CALCITE-2216:
--
Summary: Improve extensibility of AggregateReduceFunctionsRule
Key: CALCITE-2216
URL: https://issues.apache.org/jira/browse/CALCITE-2216
Project: Calcite
30 matches
Mail list logo
