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.kasnach...@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 <gvvinbl...@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 <dma...@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 <gvvinbl...@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 <dma...@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
