Julian Hyde created CALCITE-4418:
Summary: Allow Interpreter to read from JDBC input
Key: CALCITE-4418
URL: https://issues.apache.org/jira/browse/CALCITE-4418
Project: Calcite
Issue Type: Bug
Hello,
I went fast over the diff and overall the changes do not make the code that
different than before.
Moreover, the refactoring for preparing for nullable annotations seems
beneficial in any case (finalizing instance variables, adding
requireNonNull for enforcing fail fast behavior, removing u
Agree with Jiatao, I had the same experience and feeling. But it mainly depends
on the rule creator's preference.
On 2020/11/23 02:42:21, Danny Chan wrote:
> I kind of agree, but it's more like a programming specification, we can
> tell people how to write codes but they may not follow those ru
I can create a JIRA and update the code, it's minor but I think it is good
for us.
Regards!
Aron Tao
Haisheng Yuan 于2020年11月23日周一 下午5:53写道：
> Agree with Jiatao, I had the same experience and feeling. But it mainly
> depends on the rule creator's preference.
>
> On 2020/11/23 02:42:21, Danny
E, seems we don't have that.
Regards!
Aron Tao
Juan Pan 于2020年11月23日周一 下午2:54写道：
> Hi JiaTao,
>
>
> Very appreciated your share.
>
>
> Actually, what I am confused about is how to make Calcite custom adaptor
> works with other parsers.
> For example, I use a non-Calcite parser to get the
There is nothing stopping you from using adapters with SQL queries you
have parsed yourself. You simply need to assign the appropriate
convention to each table scan in the RelNode tree you pass into the
optimizer. However, if the reason for using your own parser is to be
able to have as broad suppo
+1, `step into` causes bad debug experience.
On Mon, Nov 23, 2020 at 6:13 PM JiaTao Tao wrote:
> I can create a JIRA and update the code, it's minor but I think it is good
> for us.
>
>
> Regards!
>
> Aron Tao
>
>
> Haisheng Yuan 于2020年11月23日周一 下午5:53写道：
>
> > Agree with Jiatao, I had the same
Ruben Q L created CALCITE-4419:
--
Summary: Posix regex operators cannot be used within RelBuilder
Key: CALCITE-4419
URL: https://issues.apache.org/jira/browse/CALCITE-4419
Project: Calcite
Issue
I am -0 on this change.
Most code is read many more times than it is debugged. If you expand code so
that it takes more screen area, the reader has to read more code in order to
figure out what’s going on.
Of course you can take that philosophy too far. If I have a multi-line
expression, with
Like Stamatis, I have quickly gone over the changes, and I find that the code
is not significantly different, and overall it is an improvement. Thanks for
making this change, Vladimir.
PolyNull is difficult to understand, and I don’t think we should require
developers to understand it. Therefor
I think Michael has said points that I can say. Just try to understand your
problem after reads existing threads:
Sounds like, you need to do two things:
1. Reuse Calcite adaptors and combine that with your parser to parse
queries.
2. Convert results from 1. to RelNode and let Calcite optimize, th
Sorry for the late reply Statmatis. I have recently been pretty busy on
work as it is approaching the end of the year.
The time in [1] works perfectly for me. I will share the abstract and
expected duration soon (should within this week).
-Rui
On Fri, Nov 20, 2020 at 2:11 AM Stamatis Zampetakis
I second readability over debug ability. If every function call is
decompressed to its own variable, readability can be compromised while make
it more annoy to debug because there are now so many
intermediate variables. Calcite compiles relatively quickly, it is not too
inconvenient to refactor a
Thanks for the review, Julian.
Are you willing to help with fixing the bits that you identified?
Could you suggest timeframes when you can implement that?
Julian>PolyNull is difficult to understand
I agree PolyNull is not the most obvious thing, however, "arrays vs
annotations" is even harder :)
Hey Aron,
I think you can add a watch expression on RelBuilder#peek[1] method and
like that you don't need to step in or anything like that during debugging.
Best,
Stamatis
[1]
https://github.com/apache/calcite/blob/99251a51842483bc80688364195a159b740bd53f/core/src/main/java/org/apache/calcite/t
Stamatis>I think you can add a watch expression on RelBuilder#peek[1]
method and
Good luck with EnumerableBatchNestedLoopJoinRule :-)
call.transformTo(
EnumerableBatchNestedLoopJoin.create(
convert(join.getLeft(), join.getLeft().getTraitSet()
.replace(Enume
> Are you willing to help with fixing the bits that you identified?
> Could you suggest timeframes when you can implement that?
I can’t tell whether you sincerely want my help. I’ll create a patch fixing the
three items. I’m fearful that you will take issue with what I put in the patch
and my
Julian>I can’t tell whether you sincerely want my help. I’ll create a patch
fixing the three items. I’m fearful that you will take issue with what I
put in the patch and my time will be wasted.
We can update javadocs at any time. If you want to make that simultaneously
with PR 2268, I'm ok.
Please
Hi James
My point is not all intermediate variables, please don't expand the scope,
you may not family with "relBuilder.build()", you can not run this method
twice, it's not idempotent.
I'm usually using "option+click" to direct see the expression's value, it's
so convenient, but RelBuilder#peek i
19 matches
Mail list logo
