[jira] [Updated] (CALCITE-2214) Support CREATE FUNCTION DDL
[ https://issues.apache.org/jira/browse/CALCITE-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuyi Chen updated CALCITE-2214: Description: We want to add function DDL support like this in [Vertica|https://my.vertica.com/docs/7.2.x/HTML/index.htm#Authoring/SQLReferenceManual/Statements/CREATEFUNCTIONUDF.htm]. Component/s: core > Support CREATE FUNCTION DDL > --- > > Key: CALCITE-2214 > URL: https://issues.apache.org/jira/browse/CALCITE-2214 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > > We want to add function DDL support like this in > [Vertica|https://my.vertica.com/docs/7.2.x/HTML/index.htm#Authoring/SQLReferenceManual/Statements/CREATEFUNCTIONUDF.htm]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2046) Support "CREATE LIBRARY" DDL
[
https://issues.apache.org/jira/browse/CALCITE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shuyi Chen updated CALCITE-2046:
Summary: Support "CREATE LIBRARY" DDL (was: Support "CREATE FUNCTION" DDL)
> Support "CREATE LIBRARY" DDL
>
>
> Key: CALCITE-2046
> URL: https://issues.apache.org/jira/browse/CALCITE-2046
> Project: Calcite
> Issue Type: New Feature
>Reporter: Shuyi Chen
>Assignee: Shuyi Chen
>Priority: Major
>
> We want to add DDL support for creating external function like Apache Drill
> ([https://drill.apache.org/docs/create-function-using-jar/]).
> {code:java}
> CREATE FUNCTION USING JAR '.jar';
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2214) Support CREATE FUNCTION DDL
Shuyi Chen created CALCITE-2214: --- Summary: Support CREATE FUNCTION DDL Key: CALCITE-2214 URL: https://issues.apache.org/jira/browse/CALCITE-2214 Project: Calcite Issue Type: New Feature Reporter: Shuyi Chen Assignee: Shuyi Chen -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2046) Support "CREATE FUNCTION" DDL
[
https://issues.apache.org/jira/browse/CALCITE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399432#comment-16399432
]
Shuyi Chen commented on CALCITE-2046:
-
I think we need another Jira [CREATE
FUNCTION|https://my.vertica.com/docs/7.2.x/HTML/index.htm#Authoring/SQLReferenceManual/Statements/CREATEFUNCTIONUDF.htm]
support.
Also, to load external libraries for code generation when compiling, do you
have any suggestions? I look through the documentation and code, the only
solution I can find is to use the ICookable.setParentClassLoader to replace the
classloader with another one that has the external libraries loaded. I'll
appreciate your insight.
> Support "CREATE FUNCTION" DDL
> -
>
> Key: CALCITE-2046
> URL: https://issues.apache.org/jira/browse/CALCITE-2046
> Project: Calcite
> Issue Type: New Feature
>Reporter: Shuyi Chen
>Assignee: Shuyi Chen
>Priority: Major
>
> We want to add DDL support for creating external function like Apache Drill
> ([https://drill.apache.org/docs/create-function-using-jar/]).
> {code:java}
> CREATE FUNCTION USING JAR '.jar';
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2045) Support "CREATE TYPE" DDL
[ https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399352#comment-16399352 ] Shuyi Chen edited comment on CALCITE-2045 at 3/14/18 8:29 PM: -- Hi [~julianhyde], that sounds good to me. Can you take another look at the PR at your convenience? thanks. was (Author: suez1224): [~julianhyde], sounds good to me. Can you take another look at the PR at your convenience? thanks. > Support "CREATE TYPE" DDL > - > > Key: CALCITE-2045 > URL: https://issues.apache.org/jira/browse/CALCITE-2045 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2045) Support "CREATE TYPE" DDL
[ https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399352#comment-16399352 ] Shuyi Chen commented on CALCITE-2045: - [~julianhyde], sounds good to me. Can you take another look at the PR at your convenience? thanks. > Support "CREATE TYPE" DDL > - > > Key: CALCITE-2045 > URL: https://issues.apache.org/jira/browse/CALCITE-2045 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2045) Support "CREATE TYPE" DDL
[ https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399234#comment-16399234 ] Julian Hyde commented on CALCITE-2045: -- Sorry, [~jcamachorodriguez] already started a vote for RC0, so it will miss 1.16. Let's carry on working on it, and it will be in 1.17. > Support "CREATE TYPE" DDL > - > > Key: CALCITE-2045 > URL: https://issues.apache.org/jira/browse/CALCITE-2045 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2046) Support "CREATE FUNCTION" DDL
[
https://issues.apache.org/jira/browse/CALCITE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399228#comment-16399228
]
Julian Hyde commented on CALCITE-2046:
--
Maybe we don't need JAR or JARS. Following
[Vertica|https://my.vertica.com/docs/7.2.x/HTML/index.htm#Authoring/SQLReferenceManual/Statements/CREATELIBRARY.htm],
let's have:
{code}CREATE [OR REPLACE] LIBRARY
[schema.]library-name
AS 'library-path'
[ DEPENDS 'support-path' [, 'support-path' ]* ]
[ LANGUAGE 'language' ]{code}
(as Vertica, but allowing more than one support path) for example:
{code}CREATE OR REPLACE mySchema.myLib
AS '/foo/myLib.jar'
DEPENDS '/foo/guava-23.0.jar', '/foo/jackson-2.9.jar'
LANGUAGE 'Java'{code}
> Support "CREATE FUNCTION" DDL
> -
>
> Key: CALCITE-2046
> URL: https://issues.apache.org/jira/browse/CALCITE-2046
> Project: Calcite
> Issue Type: New Feature
>Reporter: Shuyi Chen
>Assignee: Shuyi Chen
>Priority: Major
>
> We want to add DDL support for creating external function like Apache Drill
> ([https://drill.apache.org/docs/create-function-using-jar/]).
> {code:java}
> CREATE FUNCTION USING JAR '.jar';
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2211) Type of BigInteger should be BIGINT
[
https://issues.apache.org/jira/browse/CALCITE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399146#comment-16399146
]
Julian Hyde commented on CALCITE-2211:
--
Just curious, what is the JDBC type of that "bigint(20) unsigned" column? It is
definitely not BIGINT because SQL standard BIGINT is 64 bit signed. What does
MySQL print when you describe the columns in the table?
It's helpful if when we use a type name we are explicit what type system it
belongs to. For instance, when [~suez1224] mentions {{Decimal}} above he is
referring to the [C sharp decimal
type|https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/decimal],
not the SQL DECIMAL type.
> Type of BigInteger should be BIGINT
> ---
>
> Key: CALCITE-2211
> URL: https://issues.apache.org/jira/browse/CALCITE-2211
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Eyal Segal
>Assignee: Julian Hyde
>Priority: Major
>
> Vertica DB returns BigInteger values as BigInteger. It seems that
> JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to
> BIGINT.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2211) Type of BigInteger should be BIGINT
[
https://issues.apache.org/jira/browse/CALCITE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399040#comment-16399040
]
Eyal Segal edited comment on CALCITE-2211 at 3/14/18 6:23 PM:
--
It is also reproduced on MySql, with unsigned bigint column.
Consider this table:
{code:java}
create table test_table (id bigint(20) unsigned not null);
insert into test_table values (1);
{code}
Then when we fetch the result using JDBC:
{code:java}
try (Connection conn = new JDBC4Connection(db, 3306, p, "common",
"jdbc:apache:commons:dbcp:/db")) {
try (ResultSet rs = conn.prepareStatement("SELECT id FROM common.test_table
WHERE id=1").executeQuery()) {
while (rs.next()) {
System.out.print(rs.getObject("id").getClass());
}
}
}{code}
This will print "class java.math.BigInteger"
was (Author: eysegal):
It is also reproduced on MySql, with unsigned bigint column.
Consider this table:
{code:java}
create table test_table (id bigint(20) unsigned not null);
insert into test_table values (1);
{code}
Then when we fetch the result using JDBC:
{code:java}
try (Connection conn = new JDBC4Connection(db, 3306, p, "common",
"jdbc:apache:commons:dbcp:/db")) {
try (ResultSet rs = conn.prepareStatement("SELECT id FROM common.test_table
WHERE id=1").executeQuery()) {
while (rs.next()) {
System.out.print(rs.getObject("id").getClass());
}
}
}{code}
This will print java.math.BigInteger
> Type of BigInteger should be BIGINT
> ---
>
> Key: CALCITE-2211
> URL: https://issues.apache.org/jira/browse/CALCITE-2211
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Eyal Segal
>Assignee: Julian Hyde
>Priority: Major
>
> Vertica DB returns BigInteger values as BigInteger. It seems that
> JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to
> BIGINT.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2211) Type of BigInteger should be BIGINT
[
https://issues.apache.org/jira/browse/CALCITE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399040#comment-16399040
]
Eyal Segal edited comment on CALCITE-2211 at 3/14/18 6:21 PM:
--
It is also reproduced on MySql, with unsigned bigint column.
Consider this table:
{code:java}
create table test_table (id bigint(20) unsigned not null);
insert into test_table values (1);
{code}
Then when we fetch the result using JDBC:
{code:java}
try (Connection conn = new JDBC4Connection(db, 3306, p, "common",
"jdbc:apache:commons:dbcp:/db")) {
try (ResultSet rs = conn.prepareStatement("SELECT id FROM common.test_table
WHERE id=1").executeQuery()) {
while (rs.next()) {
System.out.print(rs.getObject("id").getClass());
}
}
}{code}
This will print java.math.BigInteger
was (Author: eysegal):
It is also reproduced on MySq, with unsigned bigint column.
Consider this table:
{code:java}
create table test_table (id bigint(20) unsigned not null);
insert into test_table values (1);
{code}
Then when we fetch the result using JDBC:
{code:java}
try (Connection conn = new JDBC4Connection(db, 3306, p, "common",
"jdbc:apache:commons:dbcp:/db")) {
try (ResultSet rs = conn.prepareStatement("SELECT id FROM common.test_table
WHERE id=1").executeQuery()) {
while (rs.next()) {
System.out.print(rs.getObject("id").getClass());
}
}
}{code}
This will print java.math.BigInteger
> Type of BigInteger should be BIGINT
> ---
>
> Key: CALCITE-2211
> URL: https://issues.apache.org/jira/browse/CALCITE-2211
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Eyal Segal
>Assignee: Julian Hyde
>Priority: Major
>
> Vertica DB returns BigInteger values as BigInteger. It seems that
> JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to
> BIGINT.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2211) Type of BigInteger should be BIGINT
[
https://issues.apache.org/jira/browse/CALCITE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399040#comment-16399040
]
Eyal Segal commented on CALCITE-2211:
-
It is also reproduced on MySq, with unsigned bigint column.
Consider this table:
{code:java}
create table test_table (id bigint(20) unsigned not null);
insert into test_table values (1);
{code}
Then when we fetch the result using JDBC:
{code:java}
try (Connection conn = new JDBC4Connection(db, 3306, p, "common",
"jdbc:apache:commons:dbcp:/db")) {
try (ResultSet rs = conn.prepareStatement("SELECT id FROM common.test_table
WHERE id=1").executeQuery()) {
while (rs.next()) {
System.out.print(rs.getObject("id").getClass());
}
}
}{code}
This will print java.math.BigInteger
> Type of BigInteger should be BIGINT
> ---
>
> Key: CALCITE-2211
> URL: https://issues.apache.org/jira/browse/CALCITE-2211
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Eyal Segal
>Assignee: Julian Hyde
>Priority: Major
>
> Vertica DB returns BigInteger values as BigInteger. It seems that
> JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to
> BIGINT.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-2210) Avatica - Remove JDK 7 and add JDK 9 to .travis.yml
[ https://issues.apache.org/jira/browse/CALCITE-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-2210. - Resolution: Fixed Fixed in [https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=98bf4d75ec1a7b7ee7e68b9c4f2a72840d8d63dd.] Thanks, Kevin! > Avatica - Remove JDK 7 and add JDK 9 to .travis.yml > --- > > Key: CALCITE-2210 > URL: https://issues.apache.org/jira/browse/CALCITE-2210 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: avatica-1.12.0 > > > Avatica 0.11.0 dropped support for JDK 7. However it is still in .travis.yml. > We should remove JDK 7 and add JDK 9 to .travis.yml for Avatica. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2210) Avatica - Remove JDK 7 and add JDK 9 to .travis.yml
[ https://issues.apache.org/jira/browse/CALCITE-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16398783#comment-16398783 ] ASF GitHub Bot commented on CALCITE-2210: - Github user asfgit closed the pull request at: https://github.com/apache/calcite-avatica/pull/29 > Avatica - Remove JDK 7 and add JDK 9 to .travis.yml > --- > > Key: CALCITE-2210 > URL: https://issues.apache.org/jira/browse/CALCITE-2210 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: avatica-1.12.0 > > > Avatica 0.11.0 dropped support for JDK 7. However it is still in .travis.yml. > We should remove JDK 7 and add JDK 9 to .travis.yml for Avatica. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2210) Avatica - Remove JDK 7 and add JDK 9 to .travis.yml
[ https://issues.apache.org/jira/browse/CALCITE-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16398781#comment-16398781 ] ASF GitHub Bot commented on CALCITE-2210: - Github user joshelser commented on the issue: https://github.com/apache/calcite-avatica/pull/29 I like it. It passes, and doesn't seem to add an exorbitant amount of time to the build. > Avatica - Remove JDK 7 and add JDK 9 to .travis.yml > --- > > Key: CALCITE-2210 > URL: https://issues.apache.org/jira/browse/CALCITE-2210 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: avatica-1.12.0 > > > Avatica 0.11.0 dropped support for JDK 7. However it is still in .travis.yml. > We should remove JDK 7 and add JDK 9 to .travis.yml for Avatica. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2210) Avatica - Remove JDK 7 and add JDK 9 to .travis.yml
[ https://issues.apache.org/jira/browse/CALCITE-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16398778#comment-16398778 ] ASF GitHub Bot commented on CALCITE-2210: - Github user joshelser commented on the issue: https://github.com/apache/calcite-avatica/pull/29 I'm actually ok with that. I imagine there isn't much difference in speed. Let me look at this.. > Avatica - Remove JDK 7 and add JDK 9 to .travis.yml > --- > > Key: CALCITE-2210 > URL: https://issues.apache.org/jira/browse/CALCITE-2210 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: avatica-1.12.0 > > > Avatica 0.11.0 dropped support for JDK 7. However it is still in .travis.yml. > We should remove JDK 7 and add JDK 9 to .travis.yml for Avatica. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2212) Avatica - Enforce Java version via maven-enforcer-plugin
[ https://issues.apache.org/jira/browse/CALCITE-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-2212. - Resolution: Fixed Fixed in [https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=5f1795b437b876be6a303d0ea67ceb25baf1c2cf.] Thanks Kevin! > Avatica - Enforce Java version via maven-enforcer-plugin > > > Key: CALCITE-2212 > URL: https://issues.apache.org/jira/browse/CALCITE-2212 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Josh Elser >Assignee: Kevin Risden >Priority: Critical > Fix For: avatica-1.12.0 > > > Now that jdk7 support has been dropped, we should add some logic to the build > to fail obviously when a version of Java is used that we don't support. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2212) Avatica - Enforce Java version via maven-enforcer-plugin
[ https://issues.apache.org/jira/browse/CALCITE-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16398772#comment-16398772 ] ASF GitHub Bot commented on CALCITE-2212: - Github user asfgit closed the pull request at: https://github.com/apache/calcite-avatica/pull/31 > Avatica - Enforce Java version via maven-enforcer-plugin > > > Key: CALCITE-2212 > URL: https://issues.apache.org/jira/browse/CALCITE-2212 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Josh Elser >Assignee: Kevin Risden >Priority: Critical > Fix For: avatica-1.12.0 > > > Now that jdk7 support has been dropped, we should add some logic to the build > to fail obviously when a version of Java is used that we don't support. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2212) Avatica - Enforce Java version via maven-enforcer-plugin
[ https://issues.apache.org/jira/browse/CALCITE-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16398770#comment-16398770 ] ASF GitHub Bot commented on CALCITE-2212: - Github user joshelser commented on the issue: https://github.com/apache/calcite-avatica/pull/31 +1 merging.. > Avatica - Enforce Java version via maven-enforcer-plugin > > > Key: CALCITE-2212 > URL: https://issues.apache.org/jira/browse/CALCITE-2212 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Josh Elser >Assignee: Kevin Risden >Priority: Critical > Fix For: avatica-1.12.0 > > > Now that jdk7 support has been dropped, we should add some logic to the build > to fail obviously when a version of Java is used that we don't support. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2194) Schema access authorization feature
[
https://issues.apache.org/jira/browse/CALCITE-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16398459#comment-16398459
]
Piotr Bojko commented on CALCITE-2194:
--
[~julianhyde] I know that you are in a rush during a release of 1.16.0 now. So
take your time here. In my opinion I have fulfill your requirements about the
privileges model and I am waiting only for your call about that and then will
patch minor issues like formatting or so.
But If you are ok with that and find useful to calcite I can contribute more
changes. I would like to have a factory for authentication - just like
authorization here:
{code:json}
{
"version": "1.0",
"defaultSchema": "ENHANCED",
"authorization": {
"factory": "org.apache.calcite.access.PrincipalWithOwnershipAuthFactory",
"operand": {}
},
"authentication": {
"factory": "org.apache.calcite.access.SomeAuthenticationFactory",
"operand": {}
},
"schemas": [
{code}
AuthenticationFactory could produce AuthenticationProvider (instead of existing
Fairy which name you don't like) and this provider will be hooked to some
events in calcite (mostly to creation of connection under which a principal
should be deduced). Having that - user of calcite can implement different
authentication schemes, maybe bridge the authentication from spring/jee (my
case), maybe simple deducing from connection.condig.user property.
Your call :)
> Schema access authorization feature
> ---
>
> Key: CALCITE-2194
> URL: https://issues.apache.org/jira/browse/CALCITE-2194
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.16.0
>Reporter: Piotr Bojko
>Assignee: Piotr Bojko
>Priority: Minor
>
> See:
> [https://mail-archives.apache.org/mod_mbox/calcite-dev/201711.mbox/ajax/%3C6F6E52D4-6860-4384-A1CB-A2301D05394D%40apache.org%3E]
> I've looked into the core and the notion of an user could be hard to achieved
> now.
> Though, I am able to implement the "hidden schema" feature through following
> changes:
> # JsonSchema - add a holder for the feature, boolean flag or flags field
> with enum (CACHED which now exists as a separate flag - some deprecation
> could be needed, HIDDEN)
> # CalciteSchema - pass through of a flag
> # RelOptSchema - pass through of a flag
> # CalciteCatalogReader - pass through of a flag
> # Other derivatives of RelOptSchema - mocked value, false
> # RelOptTable and impl - pass through of a flag
> # SqlValidatorImpl - validation whether object from hidden schema is used
> (in the same places like validateAccess)
> # ViewTableMacro.apply -> Schemas.analyzeView ->
> CalcitePrepareImpl.analyzeView -> CalcitePrepareImpl.parse_ ->
> CalcitePrepareImpl.CalcitePrepareImpl - this path of execution should build
> SqlValidatorImpl which has the check from point 7 disabled-
> Such feature could be useful for end users.
> If the solution is ok - I can contribute it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2206) Queries with window functions fail when using HSQLDB
[
https://issues.apache.org/jira/browse/CALCITE-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16398311#comment-16398311
]
Pavel Gubin commented on CALCITE-2206:
--
Ok, pushed remaining changes.
> Queries with window functions fail when using HSQLDB
>
>
> Key: CALCITE-2206
> URL: https://issues.apache.org/jira/browse/CALCITE-2206
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.15.0
>Reporter: Pavel Gubin
>Assignee: Julian Hyde
>Priority: Major
>
> Queries containing window functions fail when using HSQLDB (or any other DB
> that does not support window functions) because optimiser converts them to
> native SQL with window functions which are not supported by HSQLDB. For
> example:
> {code:sql}
> select "store_id", "product_id", sum("unit_sales") unit_sales, row_number()
> over (
> partition by "store_id" order by sum("unit_sales") desc
> ) row_num
> from "sales_fact_1998"
> group by "store_id", "product_id"
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2206) Queries with window functions fail when using HSQLDB
[
https://issues.apache.org/jira/browse/CALCITE-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16398214#comment-16398214
]
Julian Hyde commented on CALCITE-2206:
--
Did you push your changes? I don't see them.
bq. Why would you want to deprecate the old JdbcConverterRule constructor?
Oh, just consistency. It gets confusing when classes have multiple constructors.
> Queries with window functions fail when using HSQLDB
>
>
> Key: CALCITE-2206
> URL: https://issues.apache.org/jira/browse/CALCITE-2206
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.15.0
>Reporter: Pavel Gubin
>Assignee: Julian Hyde
>Priority: Major
>
> Queries containing window functions fail when using HSQLDB (or any other DB
> that does not support window functions) because optimiser converts them to
> native SQL with window functions which are not supported by HSQLDB. For
> example:
> {code:sql}
> select "store_id", "product_id", sum("unit_sales") unit_sales, row_number()
> over (
> partition by "store_id" order by sum("unit_sales") desc
> ) row_num
> from "sales_fact_1998"
> group by "store_id", "product_id"
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-1862) StackOverflowException in RelMdUtil.estimateFilteredRows
[
https://issues.apache.org/jira/browse/CALCITE-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16398207#comment-16398207
]
Julian Hyde commented on CALCITE-1862:
--
I've seen situations like this before. It's difficult to know whether the
rules, the engine (volcano or hep) or the statistics are at fault.
My conclusion is that the rules are in the best position to do something. They
should be recognizing that they are generating something equivalent, and not
generate it. Maybe RelBuilder.simplifier should be smarter.
> StackOverflowException in RelMdUtil.estimateFilteredRows
>
>
> Key: CALCITE-1862
> URL: https://issues.apache.org/jira/browse/CALCITE-1862
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> The query
> {code}select *
> from (
> select *
> from (
> select cast(null as integer) as d
> from "scott".emp)
> where d is null and d is null)
> where d is null;{code}
> gives
> {noformat}
> java.lang.StackOverflowError
> > at
> > org.apache.calcite.adapter.clone.ArrayTable.getStatistic(ArrayTable.java:76)
> > at
> > org.apache.calcite.prepare.RelOptTableImpl.getRowCount(RelOptTableImpl.java:224)
> > at
> > org.apache.calcite.rel.core.TableScan.estimateRowCount(TableScan.java:75)
> > at
> > org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:206)
> > at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> > at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> > at
> > org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
> > at
> > org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
> > at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> > at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> > at
> > org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
> > at
> > org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718)
> > at
> > org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:123)
> > at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> > at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> > at
> > org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
> > at
> > org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
> > at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> > at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> > at
> > org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
> > at
> > org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718){noformat}
> For a test case, add the query to misc.iq and run QuidemTest.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
