In Apache Flink, we have a syntax:
… A JOIN B for SYSTEM_TIME AS OF A.PROC_TIME
To describe a stream A join a temporal table B where we only want to join the
records with the current machine time as the time point of table B.
Is that the case Viliam described ?
Best,
Danny Chan
在 2020年3月25日
Thanks, Julian
I've opened a JIRA: CALCITE-3870 to track and a PR is as followed.
Regards!
Aron Tao
Julian Hyde 于2020年3月25日周三 上午12:55写道：
I agree that expand should default to false in ConfigBuilder.
Rationale: expand = false is the preferred modern behavior. We want
SqlToRelConverter to
Jiatao Tao created CALCITE-3870:
---
Summary: set "SqlToRelConverter.ConfigBuilder#expand" default to
false
Key: CALCITE-3870
URL: https://issues.apache.org/jira/browse/CALCITE-3870
Project: Calcite
Sorry, I need to be pedantic.
In Apache, there is no such thing as a “contributor”. There are committers and
PMC members, and there is the community - which consists of anyone in the world
who takes an interest.
Unfortunately Jira requires people to be given a particular permission in order
Hey Roman,
I've added you as a contributor to the project.
Francis
On 25/03/2020 6:47 am, Roman Kondakov wrote:
Hi everybody!
My name is Roman Kondakov. I use Calcite for building SQL layer on the
top of Apache Ignite.
I would like to join the Calcite community. I will start with minor
Maybe add that Apache Calcite empowers cloud computing: AWS Kinesis, Google
Cloud Dataflow, etc provides SQL that is using the help of Calcite. (Let me
know if I mis-understand those products if they are not using Calcite).
-Rui
On Tue, Mar 24, 2020 at 11:29 AM Stamatis Zampetakis
wrote:
>
Hi everybody!
My name is Roman Kondakov. I use Calcite for building SQL layer on the
top of Apache Ignite.
I would like to join the Calcite community. I will start with minor
tasks (I have a couple on my mind) to understand your processes better.
I would also appreciate any help.
My Jira id is
I agree with Francis. Indeed, it would be nice to have some feedback from
the people in the companies.
Apart from that here are a few quick ideas:
1) Flink, Hive, Druid, Solr, Phoenix, and many more data management systems
provide full-fledged SQL capabilities all thanks to Apache Calcite.
2)
Hi João,
Can you provide minimal reproducible test cases?
You can log a JIRA if you believe this is a bug.
- Haisheng
--
发件人：João Silva
日 期：2020年03月24日 23:40:12
收件人：
主 题：Re: NPE at VolcanoPlanner.setRoot()
Currently on 1.21.0. And
I agree that expand should default to false in ConfigBuilder.
Rationale: expand = false is the preferred modern behavior. We want
SqlToRelConverter to leave sub-queries as sub-queries (wrapping in RexSubQuery)
and then deal with them later with SubQueryRemoveRule. It is difficult for
You’re right that this is a problem.
We’d need some way to say that you don’t care which version of the product
table you are joining against. One implication would be that if you replay the
query, and the product table has changed in the mean time, you are happy to get
different results.
We
It does seem to be something that RelBuilder could do. (RexSimplify can’t
really do it, because it doesn’t know how the expression is being used.)
It’s also worth discovering why the CAST was added in the first place. It
doesn’t seem to be helpful. I think we should strive to eliminate all of
Currently on 1.21.0. And no, I didn't implement any Convention.
Stamatis Zampetakis escreveu no dia terça, 24/03/2020
à(s) 15:26:
> Hi João,
>
> Which Calcite version are you using?
>
> Did you implement your own Convention (and the method getInterface)?
>
> Best,
> Stamatis
>
> On Tue, Mar 24,
Hi João,
Which Calcite version are you using?
Did you implement your own Convention (and the method getInterface)?
Best,
Stamatis
On Tue, Mar 24, 2020 at 4:12 PM João Silva wrote:
> I keep getting a NPE exception using the method setRoot() even though my
> RelNode is not null. Does anyone
I keep getting a NPE exception using the method setRoot() even though my
RelNode is not null. Does anyone have any idea about what could be the
problem?
java.lang.NullPointerException
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.registerImpl(VolcanoPlanner.java:1654)
> at
>
The Apache Jenkins build system has built Calcite-Master (build #1655)
Status: Still Failing
Check console output at https://builds.apache.org/job/Calcite-Master/1655/ to
view the results.
I think Alibaba and a quite a few other companies[1] are heavy users of
Calcite. Perhaps someone from those companies can write up a nice little
factoid.
[1] https://calcite.apache.org/docs/powered_by.html
On 24/03/2020 8:26 pm, Stamatis Zampetakis wrote:
Hello,
There is an effort for
Hello,
There is an effort for promoting Apache projects by sharing impressive
things or highly-visible implementations/deployments.
Examples from other projects:
1) Apple Siri completes full ring replication around the world in 10
seconds using Apache HBase.
2) More than 60% of Apache
Hey,
That's a great diagnosis :)
I would guess that newCondition became non-nullable for some reason
(rexSimplify runs under RexProgramBuilder so it might be able to narrow the
nullability)
you could try invoking simplify.simplifyPreservingType() on it to see if that
would help.
> I know
IMHO, A disadvantage of supplying a default RexExecutor is that we cannot
make
sure that the reduced result is the same as the result of the execution
engine,
especially when there is some customized implementation.
Best,
Chunwei
On Fri, Mar 20, 2020 at 11:16 AM Danny Chan wrote:
> This is a
Hey Shuo!
I think that simplification should been made on join conditions - I've done a
quick check; and it seems to be working for me.
I suspected that it will be either a missing call to RexSimplify for some reason - or it is added by a forced return type correction: IIRC there are some cases
Stephan Pirnbaum created CALCITE-3869:
-
Summary: Stackoverflow with large OR statements
Key: CALCITE-3869
URL: https://issues.apache.org/jira/browse/CALCITE-3869
Project: Calcite
Issue
So how would you do a simple stream enrichment query? That is one that for
each new record in an append-only relation will join a matching record from
a mutable relation that's valid at the processing time? This use case is
common, for example in credit card fraud detection, for each transaction
Hi, Julian, That's what we do as a workaround way. we remove CAST which are
only widening nullability as what CALCITE-2695 does before applying
hash-join/sort-merge-join rule, such that equiv predicate can be split
out. I'm not sure whether it's properly for Calcite to do the 'convert
back' job,
Or convert it back to a not-nullable BOOLEAN? The join condition treats UNKNOWN
the same as FALSE, and besides UNKNOWN will never occur, so the conditions with
and without the CAST are equivalent.
Julian
> On Mar 23, 2020, at 9:34 PM, Shuo Cheng wrote:
>
> Hi all,
>
> Considering the Join
25 matches
Mail list logo
