ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Pavlukhin <vololo...@gmail.com>
Subject Re: SQL dialects supported by Calcite
Date Mon, 30 Dec 2019 14:14:48 GMT
My humble opinion here is that we should strive for one and only
dialect. I understand concerns about supporting a backward compatible
dialect. But I personally do not know whether it is practical with
Calcite. Regarding multiples dialects my forecast is that supporting
multiple dialects close by meaning to "drop-in replacement for
nothing".

пн, 30 дек. 2019 г. в 16:40, Ilya Kasnacheev <ilya.kasnacheev@gmail.com>:
>
> Hello!
>
> I think we may eventually need at least two dialects.
>
> One is "H2 compatible" for users migrating from older versions of AI. We
> may need to add a few tweaks there to make most of existing SQL code work.
> Other is "modern" in which we will remove these tweaks to get the best,
> vanilla Ignite+Calcite SQL experience.
>
> I don't think we need "Oracle dialect", this will probably create confusion
> as well as testing burden.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> сб, 28 дек. 2019 г. в 11:02, Seliverstov Igor <gvvinblade@gmail.com>:
>
> > I guess you are thinking about transparent migration from Oracle for
> > example.
> >
> > From user perspective it's really cool, but we will be forced to maintain
> > all these dialects and fully test them. Also I heard about several
> > inconsistencies between how it should and how it actually works. All these
> > issues become ours if we declare several dialects support.
> >
> > So, I think multi dialects support will bring more troubles than benefits.
> >
> > Regards,
> > Igor
> >
> > сб, 28 дек. 2019 г., 0:42 Denis Magda <dmagda@apache.org>:
> >
> > > Igor,
> > >
> > > When you are saying that we should not allow the dialect changing, are
> > you
> > > referring to changes in runtime when a node is already up-and-running?
> > > Generally, it will be more than enough if a dialect can be set statically
> > > and globally -- the user selects the dialect for the entire cluster via a
> > > configuration parameter and starts the nodes after that.
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Fri, Dec 27, 2019 at 7:05 AM Seliverstov Igor <gvvinblade@gmail.com>
> > > wrote:
> > >
> > > > Denis,
> > > >
> > > > > Is it true that Calcite can parse MySQL, Oracle
> > > >
> > > > Yes, it can.
> > > >
> > > > > Do I need to select a dialect globally or can it be set on a
> > per-query
> > > > > level?
> > > >
> > > > Technically a parser, a validator, a planner, other components are
> > > created
> > > > and configured for each query call (because they are stateful). So you
> > > may
> > > > configure it per query, or hardcode a desired dialect, or get it from
> > > > configuration - it’s up to you, but we expect parser configuration to
> > be
> > > > (more or less) static, it is a part of initial framework
> > configuration. I
> > > > think we should not allow such parameters (as a dialect) changing.
> > > >
> > > > Regards,
> > > > Igor
> > > >
> > > > > 27 дек. 2019 г., в 07:47, Denis Magda <dmagda@apache.org>
> > написал(а):
> > > > >
> > > > > Igor S., Roman and others who involved in Calcite prototyping,
> > > > >
> > > > > Is it true that Calcite can parse MySQL, Oracle, ANSI-99 and other
> > > > dialects
> > > > > as suggested by this page?
> > > > >
> > > >
> > >
> > https://calcite.apache.org/apidocs/org/apache/calcite/sql/validate/SqlConformanceEnum.html
> > > > >
> > > > > Do I need to select a dialect globally or can it be set on a
> > per-query
> > > > > level?
> > > > >
> > > > > -
> > > > > Denis
> > > >
> > > >
> > >
> >



-- 
Best regards,
Ivan Pavlukhin

Mime
View raw message