To be pedantic, that is the MATCH_RECOGNIZE function in Oracle CQL (i.e. their
event processing language) but MATCH_RECOGNIZE in Oracle’s SQL dialect has not
changed [2]. There’s a reason that it’s included in the streaming language but
not SQL. Making predicates depend on data arrival time
org
> >:
>
> > Hi Julian Hyde,
> >
> > Thanks for your feedback about the MATCH_RECOGNIZE functionality
> > enhancement. I'll give some explanations for the enhancement:
> >
> > - In the MATCH_RECOGNIZE, the WITHIN clause is an optional clause that
>
t; Thanks for your feedback about the MATCH_RECOGNIZE functionality
> enhancement. I'll give some explanations for the enhancement:
>
> - In the MATCH_RECOGNIZE, the WITHIN clause is an optional clause that
> outputs a pattern_clause match if and only if the match occurs within the
>
Hi Julian Hyde,
Thanks for your feedback about the MATCH_RECOGNIZE functionality enhancement.
I'll give some explanations for the enhancement:
- In the MATCH_RECOGNIZE, the WITHIN clause is an optional clause that outputs
a pattern_clause match if and only if the match occurs within
> After investigating the usage of MATCH_RECOGNIZE, I have created a JIRA
> ticket '[CALCITE-5202] Support for MATCH_RECOGNIZE functionality enhancement'.
>
>
>
>
> A MATCH_RECOGNIZE clause enables the following tasks:
>
>
>
>
> - Logically partition and order
Hi everyone,
After investigating the usage of MATCH_RECOGNIZE, I have created a JIRA ticket
'[CALCITE-5202] Support for MATCH_RECOGNIZE functionality enhancement'.
A MATCH_RECOGNIZE clause enables the following tasks:
- Logically partition and order the data that is used
that such an approach will fail for more complicated
patterns than `BEGIN !END`, for example determining on which event did the
pattern `A B{1,N} A{1,N} B` time out does not seem suitable for such an
approach. Moreover, this way of proceeding seems like a workaround of
MATCH_RECOGNIZE limitations
Is there a better way?
I'm am idealist with regard to streaming SQL semantics, and I'm going
to make the 'slippery slope' argument that if we add a TIMEOUT
parameter to MATCH_RECOGNIZE, won't we also need to add it to GROUP BY
and JOIN? (Because those are also "blocking" operators.)
Flink SQL MATCH_RECOGNIZE
syntax to cover for the case of the absence of an event. Such an enrichment
would help our company solve a business case containing timed-out patterns
handling. An example of usage of such a clause from Flink training exercises
could be a task of identification of taxi
Axis created CALCITE-3720:
-
Summary: failed to validate the field in match_recognize phase
Key: CALCITE-3720
URL: https://issues.apache.org/jira/browse/CALCITE-3720
Project: Calcite
Issue Type: Bug
Julian Feinauer created CALCITE-3302:
Summary: Add support for CLASSIFIER() command in MATCH_RECOGNIZE
Key: CALCITE-3302
URL: https://issues.apache.org/jira/browse/CALCITE-3302
Project: Calcite
Julian Feinauer created CALCITE-3294:
Summary: Implement FINAL Clause for MATCH_RECOGNIZE
Key: CALCITE-3294
URL: https://issues.apache.org/jira/browse/CALCITE-3294
Project: Calcite
Issue
Hi all,
I finally finished to bring the joint work on MATCH_RECOGNIZE to a state where
at least two non-trivial Tests work, see [3].
The Work is based on a lot of preliminary work of Hongze and Julian (Hyde)
which was done over a period of over a year, therefore the code is rather large.
I also
ian
> On Jan 9, 2019, at 9:13 AM, Julian Feinauer
wrote:
>
> Hi all,
>
> as discussed in earlier exchanges (see [1]), I started to work on
implementing MATCH_RECOGNIZE based on Julian (Hydes) work [2].
> I think I made some progress and resol
to-end, then start adding features to the engine. I still think
that’s a good plan.
Julian
> On Jan 9, 2019, at 9:13 AM, Julian Feinauer
> wrote:
>
> Hi all,
>
> as discussed in earlier exchanges (see [1]), I started to work on
> implementing MATCH_RECOGNIZE based on Julian (H
Hi all,
as discussed in earlier exchanges (see [1]), I started to work on implementing
MATCH_RECOGNIZE based on Julian (Hydes) work [2].
I think I made some progress and resolved some of the problems but I’m at a
stage now where I’d need some advice from more seasoned Calcite dev’s on how
creation and keep only
the epsilon removal.
I can do this if you want.
To your other point. I did never intention to step on your feet with this and I
really have to excuse for that. My only intention was to help get the
MATCH_RECOGNIZE implementation working as offered in recent conversations. So I
I remembered another reason I didn’t make the automaton deterministic. For
MATCH_RECOGNIZE, any given row can match multiple symbols. Thus it’s not like
regex matching, where the 3rd character of the string is either a or b. The
third row can match symbols A and B simultaneously. To go
hors (“^” and “$”) supported by Oracle? If so can you point me to
>>> the spec/examples. I am surprised that anything to do with patterns needs
>>> see beyond the boundaries of the current partition. I had assumed that each
>>> partition has its own state machine an
ot;) to get started with the code.
>>> I would highly appreciate if you (Julian H) could check this code (I
made a PR to your branch).
>>> Then, what else did you consider as necessary for the implementation?
>>> I thought about anchors ("^", "$")
>
>>> it's once again me, JulianF.
>>> I started work on the Automaton / Matcher and implemented OR and OPTIONAL
>>> ("?") to get started with the code.
>>> I would highly appreciate if you (Julian H) could check this code (I made a
>>&
y for the implementation?
>> I thought about anchors ("^", "$") but this would need a little bit of
extra changes in the PartitionStates, as far as I see it (to check when we
"enter" a partition and when we "leave".
>>
>> Be
eed a little bit of
extra changes in the PartitionStates, as far as I see it (to check when we
"enter" a partition and when we "leave".
>
> Best
> JulianF
>
> Am 25.12.18, 20:38 schrieb "Julian Feinauer"
:
>
>Hi Julian
Am 25.12.18, 20:38 schrieb "Julian Feinauer" :
>
>Hi Julian,
>
>as I already declared my interest in MATCH_RECOGNIZE and offered my help,
> I plan to do some things in the next one or two weeks.
>Thus, I wanted to start based on your branch (“1935-match-recognize”).
&
Hi Julian,
as I already declared my interest in MATCH_RECOGNIZE and offered my help, I
plan to do some things in the next one or two weeks.
Thus, I wanted to start based on your branch (“1935-match-recognize”).
I have some problems getting it to run.
Is it possible that there are some files
Dawid Wysakowicz created CALCITE-2746:
-
Summary: Cryptic exception when expression used in PARTITION BY
clause in MATCH_RECOGNIZE
Key: CALCITE-2746
URL: https://issues.apache.org/jira/browse/CALCITE-2746
subsets clause order for MATCH_RECOGNIZE
Hi Jiayi,
not sure what you mean by elements' order in SUBSET, so I'd try to rephrase it.
What I mean is that the order of pattern variables in SUBSET clause does not
matter. User can put them in whatever order he/she likes. LAST/FIRST etc. will
account
Sender:* Dawid Wysakowicz
> *Recipient:* dev; Julian
> Hyde; bupt_ljy
> *Date:* Sunday, Dec 16, 2018 20:08
> *Subject:* Re: Problems about subsets clause order for MATCH_RECOGNIZE
>
> Hi Jiayi,
>
> I don't think it should any difference what is the order in the SUBSET
> clau
for MATCH_RECOGNIZE
Hi Jiayi, I don't think it should any difference what is the order in the
SUBSET clause. The PATTERN clause specifies the definitive order of pattern
variables. SUBSET clause just groups them as a single entity you can reference.
Therefore LAST/FIRST/PREV/NEXT/AFTER MATCH etc. will take
into account only order in the PATTERN clause.
Best,
Dawid
On 16/12/2018 08:07, Julian Hyde wrote:
> I don’t understand MATCH_RECOGNIZE well enough to give an opinion. Is there a
> query that gives different results on Oracle if you change the order of items
> in SUBSET?
>
> It seems
I don’t understand MATCH_RECOGNIZE well enough to give an opinion. Is there a
query that gives different results on Oracle if you change the order of items
in SUBSET?
It seems that the parser preserves the order of items in the subset, but the
SqlToRelConverter does not, hence the line
Hi all,
It’s my first time to send emails to Calcite developers. It’s a really good
project and many projects benefit from it.
Now I’ve encountered a problem about the subsets for MATCH_RECOGNIZE in
thetestMatchRecognizeSubset1() testing. From the results, I can tell
that"subset
Dian Fu created CALCITE-2739:
Summary: NPE will thrown if the MEASURES statement contains IN in
MATCH_RECOGNIZE
Key: CALCITE-2739
URL: https://issues.apache.org/jira/browse/CALCITE-2739
Project: Calcite
Over thanksgiving, I started working on MATCH_RECOGNIZE again. I wrote a
standalone class called Automaton that allows you to build patterns (basically
regular expressions, but sufficient for the PATTERN sub-clause of
MATCH_RECOGNIZE), and execute them in a unit test.
Would someone like
Dawid Wysakowicz created CALCITE-2708:
-
Summary: UDAGs are not verified for single pattern variable in
MATCH_RECOGNIZE
Key: CALCITE-2708
URL: https://issues.apache.org/jira/browse/CALCITE-2708
Dawid Wysakowicz created CALCITE-2707:
-
Summary: Information about distinct aggregation is lost in
MATCH_RECOGNIZE
Key: CALCITE-2707
URL: https://issues.apache.org/jira/browse/CALCITE-2707
ly, Apache Flink released their MATCH_RECOGNIZE Implementation
yesterday.
So I recall that you and Zhigiang He did something on this.
I would like to have such a feature in Calcite (as stated in the other
mail) and could try to go into this a bit with a colleague of mine and give a
bit
Hi Julian,
I decided to reply to this (old) email, because here some facts are noted.
Funnily, Apache Flink released their MATCH_RECOGNIZE Implementation yesterday.
So I recall that you and Zhigiang He did something on this.
I would like to have such a feature in Calcite (as stated in the other
I agree. It would be good to look over the Flink implementation and see whether
we can borrow/steal. To be be clear, Calcite already has support for
MATCH_RECOGNIZE in SQL parser, validator, and relational algebra. It just does
not have an implementation. And we’re not trying to be better than
Hi Julian,
I decided to reply to this (old) email, because here some facts are noted.
Funnily, Apache Flink released their MATCH_RECOGNIZE Implementation yesterday.
So I recall that you and Zhigiang He did something on this.
I would like to have such a feature in Calcite (as stated in the other
Fei Feng created CALCITE-2633:
-
Summary: match_recognize all rows per match return type bug
Key: CALCITE-2633
URL: https://issues.apache.org/jira/browse/CALCITE-2633
Project: Calcite
Issue Type
at how Calcite runs its Quidem tests.
> >>> Not sure if this is a format that we could easily adopt to, but maybe
> its
> >>> possible to put a test data set, queries, and results in a more
> portable
> >>> format.
> >>>
> >>> Best, Fabian
&
Quidem tests.
>>> Not sure if this is a format that we could easily adopt to, but maybe its
>>> possible to put a test data set, queries, and results in a more portable
>>> format.
>>>
>>> Best, Fabian
>>>
>>>
>>>
>>>
&g
if this is a format that we could easily adopt to, but maybe its
> > possible to put a test data set, queries, and results in a more portable
> > format.
> >
> > Best, Fabian
> >
> >
> >
> >
> >
> > 2018-07-31 19:54 GMT+02:00 Julian Hy
>
> 2018-07-31 19:54 GMT+02:00 Julian Hyde :
>
>> I’m delighted that Flink is getting full SQL support for MATCH_RECOGNIZE.
>>
>> Sounds like it might be challenging to share the implementation, but could
>> we perhaps share the test suite? (I.e. a set of SQL
could easily adopt to, but maybe its
possible to put a test data set, queries, and results in a more portable
format.
Best, Fabian
2018-07-31 19:54 GMT+02:00 Julian Hyde :
> I’m delighted that Flink is getting full SQL support for MATCH_RECOGNIZE.
>
> Sounds like it might be ch
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
Le lun. 23 juil. 2018 à 13:54, Julian Hyde a écrit :
> >
> > For quite a while we have had partial support for MATCH_RECOGNIZE. We
> support it in the parser and validator, but there is no runtime
> implementation. It’s a shame, because MATCH_RECOGNIZE is an incredibly
> powerful S
for keeping this moving Julian!
--
Michael Mior
mm...@apache.org
Le lun. 23 juil. 2018 à 13:54, Julian Hyde a écrit :
>
> For quite a while we have had partial support for MATCH_RECOGNIZE. We support
> it in the parser and validator, but there is no runtime implementation. It’s
> a sh
For quite a while we have had partial support for MATCH_RECOGNIZE. We support
it in the parser and validator, but there is no runtime implementation. It’s a
shame, because MATCH_RECOGNIZE is an incredibly powerful SQL feature for both
traditional SQL (it’s in Oracle 12c) and for continuous
Dian Fu created CALCITE-2033:
Summary: Support followed by in pattern definition for
MATCH_RECOGNIZE
Key: CALCITE-2033
URL: https://issues.apache.org/jira/browse/CALCITE-2033
Project: Calcite
Julian Hyde created CALCITE-1935:
Summary: Reference implementation for MATCH_RECOGNIZE
Key: CALCITE-1935
URL: https://issues.apache.org/jira/browse/CALCITE-1935
Project: Calcite
Issue Type
Dian Fu created CALCITE-1911:
Summary: Support within clause in MATCH_RECOGNIZE
Key: CALCITE-1911
URL: https://issues.apache.org/jira/browse/CALCITE-1911
Project: Calcite
Issue Type: Bug
Zhiqiang He created CALCITE-1773:
Summary: Add Test sql validator test for Pattern skip syntax in
MATCH_RECOGNIZE
Key: CALCITE-1773
URL: https://issues.apache.org/jira/browse/CALCITE-1773
Project
Zhiqiang He created CALCITE-1689:
Summary: Remove PATTERN_DEFINE_AS in SqlStdOperatorTable for
match_recognize
Key: CALCITE-1689
URL: https://issues.apache.org/jira/browse/CALCITE-1689
Project
Zhiqiang He created CALCITE-1686:
Summary: FINAL and other functions should not be visible outside
of MATCH_RECOGNIZE
Key: CALCITE-1686
URL: https://issues.apache.org/jira/browse/CALCITE-1686
Project
Zhiqiang He created CALCITE-1647:
Summary: Classifier and match_number syntax support for
MATCH_RECOGNIZE
Key: CALCITE-1647
URL: https://issues.apache.org/jira/browse/CALCITE-1647
Project: Calcite
Zhiqiang He created CALCITE-1645:
Summary: Row per match syntax support for MATCH_RECOGNIZE
Key: CALCITE-1645
URL: https://issues.apache.org/jira/browse/CALCITE-1645
Project: Calcite
Issue
Zhiqiang He created CALCITE-1646:
Summary: Partition by and order by syntax support for
MATCH_RECOGNIZE
Key: CALCITE-1646
URL: https://issues.apache.org/jira/browse/CALCITE-1646
Project: Calcite
Zhiqiang He created CALCITE-1644:
Summary: RelToSql for MATCH_RECOGNIZE
Key: CALCITE-1644
URL: https://issues.apache.org/jira/browse/CALCITE-1644
Project: Calcite
Issue Type: Sub-task
Zhiqiang He created CALCITE-1643:
Summary: SqlToRel for MATCH_RECOGNIZE
Key: CALCITE-1643
URL: https://issues.apache.org/jira/browse/CALCITE-1643
Project: Calcite
Issue Type: Sub-task
Zhiqiang He created CALCITE-1641:
Summary: MATCH_RECOGNIZE syntax support for calcite
Key: CALCITE-1641
URL: https://issues.apache.org/jira/browse/CALCITE-1641
Project: Calcite
Issue Type
Julian Hyde created CALCITE-1570:
Summary: Add MATCH_RECOGNIZE operator, for event pattern-matching
Key: CALCITE-1570
URL: https://issues.apache.org/jira/browse/CALCITE-1570
Project: Calcite
63 matches
Mail list logo
