I've seen the commit coming through and I do like the approach of keeping
the execution logic separate, thanks Julian!
Best,
Stamatis
On Mon, Jun 1, 2020 at 9:02 PM Julian Hyde wrote:
> Just to finish this thread... I've now merged 3946.
>
> I did what Stamatis suggested, and moved the DDL
Just to finish this thread... I've now merged 3946.
I did what Stamatis suggested, and moved the DDL classes into core.
However, I kept the execution logic (e.g. creating the table when
someone sends a SqlCreateTable command) in server. To do this, I
created a new interface DdlExecutor, and moved
Thanks for the feedback, everyone. Based on the feedback I will move
the DDL classes to Core. I reserve the right to reverse direction if
those DDL classes start changing in weird ways due to dialect
requirements in Babel.
If you have further comments, let's discuss in
Hello,
I prefer a bit more the alternative of putting all DDL classes into "core".
When people talk about an SQL parser usually they mean the complete beast
(DQL, DDL, DML).
Personally, I wouldn't be surprised to find DDL in "core", especially since
DML is already in.
The dependency from
Il Ven 15 Mag 2020, 22:26 Julian Hyde ha scritto:
> Currently, there is no DDL in Calcite's "core" module (or its SQL
> parser) and the SQL parser in the "server" module adds DDL extensions
> for Calcite's object types.
>
> There is a PR [1][2] to add support for "CREATE TABLE" to Babel, and
>
Currently, there is no DDL in Calcite's "core" module (or its SQL
parser) and the SQL parser in the "server" module adds DDL extensions
for Calcite's object types.
There is a PR [1][2] to add support for "CREATE TABLE" to Babel, and
it makes "babel" extend the "server" module. In particular, it
