[jira] [Comment Edited] (CALCITE-1940) Implement dialect specific support for sequences
[
https://issues.apache.org/jira/browse/CALCITE-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16149506#comment-16149506
]
Julian Hyde edited comment on CALCITE-1940 at 8/31/17 7:55 PM:
---
bq. I somehow need to know in the SqlWriter which dialect a schema uses so that
I can call the appropriate unparse method.
Run {{JdbcAdapterTest.testFilterUnionPlan}} in the debugger with a breakpoint
in {{JdbcToEnumerableConverter.generateSql(SqlDialect)}}. You'll see that the
dialect comes from the convention of the input to the
{{JdbcToEnumerableConverter}}. That input is a {{JdbcRel}}, its convention is
an instance of {{JdbcConvention}}, and {{JdbcConvention}} has a {{sqlDialect}}
field.
In a hybrid plan (say joining a table in MySQL to a table in PostgreSQL) there
will be two instances of {{JdbcConvention}} with different dialects.
So you see the dialect is not associated with the schema. It is associated with
the {{JdbcRel}} via {{JdbcConvention}}.
It is conceivable that we would send just a {{JdbcValues}} to PostgreSQL and
generate "select 1 union select 2". There is no schema in play because there is
no table yet we still know to use PostgreSQL dialect.
was (Author: julianhyde):
bw. I somehow need to know in the SqlWriter which dialect a schema uses so that
I can call the appropriate unparse method.
Run {{JdbcAdapterTest.testFilterUnionPlan}} in the debugger with a breakpoint
in {{JdbcToEnumerableConverter.generateSql(SqlDialect)}}. You'll see that the
dialect comes from the convention of the input to the
{{JdbcToEnumerableConverter}}. That input is a {{JdbcRel}}, its convention is
an instance of {{JdbcConvention}}, and {{JdbcConvention}} has a {{sqlDialect}}
field.
In a hybrid plan (say joining a table in MySQL to a table in PostgreSQL) there
will be two instances of {{JdbcConvention}} with different dialects.
So you see the dialect is not associated with the schema. It is associated with
the JdbcRel via JdbcConvention.
It is conceivable that we send just a JdbcValues to PostgreSQL and generate
"select 1 union select 2". There is no schema in play because there is no table
yet we still know to use PostgreSQL dialect.
> Implement dialect specific support for sequences
>
>
> Key: CALCITE-1940
> URL: https://issues.apache.org/jira/browse/CALCITE-1940
> Project: Calcite
> Issue Type: Improvement
>Reporter: Christian Beikov
>Assignee: Julian Hyde
>
> The Calcite parser and validator already supports sequences but the push down
> to the JDBC level is currently limited. SInce sequences are not supported on
> all DBMS every sql dialect should have the possibility to render it's own way
> of extracting sequence information or incrementing the value.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1972) Create .sha512 and .md5 digests for release artifacts
[ https://issues.apache.org/jira/browse/CALCITE-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16149466#comment-16149466 ] Julian Hyde commented on CALCITE-1972: -- Good question (since we only have room for one in the web UI). Yes, it should point to the .sha512. > Create .sha512 and .md5 digests for release artifacts > - > > Key: CALCITE-1972 > URL: https://issues.apache.org/jira/browse/CALCITE-1972 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Michael Mior > Fix For: 1.14.0 > > > Following CALCITE-1329 we currently generate a .mds file containing multiple > digests, but breaches Apache policy for the file names that can be generated. > We should instead generate a file with .sha512 suffix containing a SHA512 > digest. > No need to generate MD5 or SHA1; these are no longer secure. > Steps: > * in pom.xml, modify the checksum-maven-plugin configuration; > * in HOWTO.md, remove the steps to generate the .mds file; > * in site/downloads/index.md, modify the "assign digest" logic for releases > 1.14 and later. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1940) Implement dialect specific support for sequences
[
https://issues.apache.org/jira/browse/CALCITE-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16149174#comment-16149174
]
Chris Baynes commented on CALCITE-1940:
---
I tried this out with postgres and noticed a problem - postgres (unlike other
dbs) already returns a list of sequences in the jdbc metadata. So the table map
building fails because of duplicates. It probably makes sense to just always
skip {{SEQUENCE}} and {{TEMPORARY_SEQUENCE}} in the loop, and only get them
from the dialect sequence information.
I can't really comment right now on your dialect handling improvement, since
I'm still not sure why the dialect handling here needs something different than
what already exists. The dialect handlers are already able to push-down calls
to different dbs as long as the planner finds the right plan.
> Implement dialect specific support for sequences
>
>
> Key: CALCITE-1940
> URL: https://issues.apache.org/jira/browse/CALCITE-1940
> Project: Calcite
> Issue Type: Improvement
>Reporter: Christian Beikov
>Assignee: Julian Hyde
>
> The Calcite parser and validator already supports sequences but the push down
> to the JDBC level is currently limited. SInce sequences are not supported on
> all DBMS every sql dialect should have the possibility to render it's own way
> of extracting sequence information or incrementing the value.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1940) Implement dialect specific support for sequences
[
https://issues.apache.org/jira/browse/CALCITE-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16148807#comment-16148807
]
Christian Beikov commented on CALCITE-1940:
---
I need the dialect since I have to call the unparse method on it. If we have a
query like e.g. "select next value for s1.seq, next value for s2.seq" and s1
and s2 are schemas that have different dialects, I have to unparse the sequence
call once for the dialect of s1 and once for s2. I somehow need to know in the
{{SqlWriter}} which dialect a schema uses so that I can call the appropriate
unparse method.
Could you([~chris-baynes]) maybe comment on the mailing list thread
"JdbcAdapter Sort Limit and Offset" which is somewhat related in the overall
discussion about how to handle the different dialect quirks. I'd like to
essentially merge the {{Handler}} and other methods into a DBMS specific
{{SqlDialect}} implementation and do the dialect construction through a
configurable factory.
> Implement dialect specific support for sequences
>
>
> Key: CALCITE-1940
> URL: https://issues.apache.org/jira/browse/CALCITE-1940
> Project: Calcite
> Issue Type: Improvement
>Reporter: Christian Beikov
>Assignee: Julian Hyde
>
> The Calcite parser and validator already supports sequences but the push down
> to the JDBC level is currently limited. SInce sequences are not supported on
> all DBMS every sql dialect should have the possibility to render it's own way
> of extracting sequence information or incrementing the value.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1970) Release Calcite 1.14.0
[ https://issues.apache.org/jira/browse/CALCITE-1970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16148754#comment-16148754 ] Michael Mior commented on CALCITE-1970: --- True. Blockers just seemed like an easy way to track things which we're currently aiming to get in this release. I don't expect all the remaining issues to make it. > Release Calcite 1.14.0 > -- > > Key: CALCITE-1970 > URL: https://issues.apache.org/jira/browse/CALCITE-1970 > Project: Calcite > Issue Type: Bug >Reporter: Michael Mior >Assignee: Michael Mior > Fix For: 1.14.0 > > > Release Apache Calcite 1.14.0. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1972) Create .sha512 and .md5 digests for release artifacts
[ https://issues.apache.org/jira/browse/CALCITE-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16148690#comment-16148690 ] Michael Mior commented on CALCITE-1972: --- I assume we should have the linked digest for the downloads be the sha256 now? > Create .sha512 and .md5 digests for release artifacts > - > > Key: CALCITE-1972 > URL: https://issues.apache.org/jira/browse/CALCITE-1972 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Michael Mior > Fix For: 1.14.0 > > > Following CALCITE-1329 we currently generate a .mds file containing multiple > digests, but breaches Apache policy for the file names that can be generated. > We should instead generate a file with .sha512 suffix containing a SHA512 > digest. > No need to generate MD5 or SHA1; these are no longer secure. > Steps: > * in pom.xml, modify the checksum-maven-plugin configuration; > * in HOWTO.md, remove the steps to generate the .mds file; > * in site/downloads/index.md, modify the "assign digest" logic for releases > 1.14 and later. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
