I’m not a fan of shading. It doesn’t make things simpler; it makes them
complicated in a different way. But of course people can take the
Calcite/Avatica jars and create their own shaded/fat artifacts. I think that’s
the simplest and least disruptive solution for people who don’t like adding
Hi colleagues,
Thank you for the valuable feedback. The problem is indeed complex. I share
the worry that complete decoupling might be too disruptive for users, since
they will observe compilation problems when migrating to the newer version,
and will have to update their dependencies, which also
I like the idea. But I have the same worry as Haisheng.
Best,
Chunwei
On Wed, Nov 25, 2020 at 3:07 PM Xin Wang wrote:
> +1 for this idea. We only use the parser/optimizer part.
>
> JiaTao Tao 于2020年11月25日周三 下午2:38写道：
>
> > +1 for this idea, I have been developing Calcite for a long
+1 for this idea. We only use the parser/optimizer part.
JiaTao Tao 于2020年11月25日周三 下午2:38写道：
> +1 for this idea, I have been developing Calcite for a long time(counting
> during project Kylin), we all treat calcite as an optimizer, but we need to
> consider overhead.
>
> I aggre with Stamatis:
+1 for this idea, I have been developing Calcite for a long time(counting
during project Kylin), we all treat calcite as an optimizer, but we need to
consider overhead.
I aggre with Stamatis: "since those dependencies were not causing any real
trouble."
What really troubling me is that when we
Il Mer 25 Nov 2020, 05:57 Haisheng Yuan ha scritto:
> > I would like to propose to decouple the "core" module from "ling4j" and
> Avatica.
> I like the idea.
>
> Moving Enumerable out of core may be time consuming and disruptive,
> because many core tests are using Enumerable to verify plan
> I would like to propose to decouple the "core" module from "ling4j" and
> Avatica.
I like the idea.
Moving Enumerable out of core may be time consuming and disruptive, because
many core tests are using Enumerable to verify plan quality and correctness.
Best,
Haisheng
On 2020/11/24 23:42:19,
Frankly speaking, "common" naming looks bad (it is hard to tell what should
go into common and what should not), and "shading" is hard as well.
Shaded dependencies cause issues for IDEs and so on.
I would prefer non-shaded dependencies if possible.
I believe we have discussed "moving enumerable
Hi Vladimir,
Personally, I like the idea.
I had similar thoughts in the past but it didn't try to break it down since
those dependencies were not causing any real trouble.
Let's see what the others think.
Best,
Stamatis
On Tue, Nov 24, 2020 at 7:30 PM Vladimir Ozerov wrote:
> Hi colleagues,
Hi colleagues,
Many Calcite integrations use only part of the framework. Specifically, it
is common to use only the parser/optimizer part. JDBC and runtime are used
less frequently because they are not very well suited for mature processing
engines (e.g. Enumerable runs out of memory easily).
10 matches
Mail list logo
