[jira] [Resolved] (CALCITE-1342) ProjectPusher should use rel factories when creating new rels, e.g. project/filter
[ https://issues.apache.org/jira/browse/CALCITE-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] MinJi Kim resolved CALCITE-1342. Resolution: Fixed Fix Version/s: 1.9.0 > ProjectPusher should use rel factories when creating new rels, e.g. > project/filter > -- > > Key: CALCITE-1342 > URL: https://issues.apache.org/jira/browse/CALCITE-1342 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > Fix For: 1.9.0 > > > I was playing around with some new ideas in drill, and wanted to use > ProjectPusher, which has a lot of useful utility functions. ProjectPusher > returns new nodes, but they are LogicalProjects/LogicalFilters. It would be > more useful if the user of ProjectPusher could specify the rel factories to > use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1371) PreparedStatement does not process Date type correctly
Billy(Yiming) Liu created CALCITE-1371:
--
Summary: PreparedStatement does not process Date type correctly
Key: CALCITE-1371
URL: https://issues.apache.org/jira/browse/CALCITE-1371
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.8.0
Reporter: Billy(Yiming) Liu
Assignee: Julian Hyde
Priority: Minor
I have problem when passing date parameter in PreparedStatement. Following is
the sample code:
TimeZone tzUtc = TimeZone.getTimeZone("UTC");
Calendar cUtc = Calendar.getInstance(tzUtc);
cUtc.set(2013, 10, 5, 0, 0, 0);
java.sql.Date passSqlDate = new java.sql.Date(cUtc.getTimeInMillis());
statement.setDate(1, passSqlDate, cUtc);
I try to pass Date'2013/11/5' to the database, but from the debug info I found
the
database received '2013/10/4' (GMT -8 Timezone) always. It ignored the Calendar
I passed in.
There are some Calcite code a little strange, I have marked by color:
Why setTimestamp and setTime have effective parameter 'calendar', but setDate
ignore the
parameter. Is that the root cause?
AvaticaSite.java
Line 189-199
public void setTimestamp(Timestamp x, Calendar calendar) {
slots[index] = wrap(ColumnMetaData.Rep.JAVA_SQL_TIMESTAMP, x, calendar);
}
public void setTime(Time x, Calendar calendar) {
slots[index] = wrap(ColumnMetaData.Rep.JAVA_SQL_TIME, x, calendar);
}
public void setDate(Date x, Calendar cal) {
slots[index] = wrap(ColumnMetaData.Rep.JAVA_SQL_DATE, x, calendar);
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1110) remove or relocate shaded jackson in Avatica
[
https://issues.apache.org/jira/browse/CALCITE-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15469142#comment-15469142
]
Josh Elser commented on CALCITE-1110:
-
Hi [~minjikim].
I think the approach (if/when I get to it myself), would be to provide shaded
and non-shaded versions of the Avatica "client" artifact. CALCITE-1224 covers
this one.
As I see it, this solves two cases for us:
# When you just want to use Avatica and don't want to worry about dependencies,
you use the shaded artifact and won't have any conflict (because the
dependencies are included and relocated).
# When you want to integrate Avatica with specific versions of Guava, Jackson,
etc, you can use the non-shaded client and provide the dependencies on your
applicaiton's classpath. There is some amount of increased test burden to make
sure that Avatica actually works with the versions of the dependencies you want
to use as a user (we only do minor testing of a range of Guava versions
presently).
Does that make sense? It is by no means the only way forward, and anything
you'd like to contribute would be a great addition, I'm sure.
> remove or relocate shaded jackson in Avatica
>
>
> Key: CALCITE-1110
> URL: https://issues.apache.org/jira/browse/CALCITE-1110
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Affects Versions: 1.6.0, 1.5.0
>Reporter: Kai Gülzau
>Assignee: Josh Elser
>Priority: Critical
> Fix For: avatica-1.9.0
>
>
> The avatica jar includes a shaded version of jackson under the original
> package path.
> This shaded version interferes with other jackson versions in the classpath.
> Currently this prevents us from using jackson functionality which is only
> implemented in newer versions.
> https://mail-archives.apache.org/mod_mbox/calcite-dev/201602.mbox/%3C977C7450-18F4-48E2-A970-69B7E3E1BD2C%40apache.org%3E
> {quote}
> Is it reasonable to have a maven profile that uses jackson as “provided”[1]
> rather than shading? This would not be the default — the default would be
> continue to use a shaded version of jackson (relocated to
> org.apache.calcite.jackson, as Josh suggests) — but folks looking to embed
> calcite/avatica in a container might appreciate a lighter weight option.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-1334) Convert predicates on EXTRACT function calls into date ranges
[
https://issues.apache.org/jira/browse/CALCITE-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-1334.
--
Resolution: Fixed
Fix Version/s: 1.9.0
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/87435a9b.
> Convert predicates on EXTRACT function calls into date ranges
> -
>
> Key: CALCITE-1334
> URL: https://issues.apache.org/jira/browse/CALCITE-1334
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
> Labels: druid
> Fix For: 1.9.0
>
>
> We would like to convert predicates on date dimension columns into date
> ranges. This is particularly useful for Druid, which has a single timestamp
> column.
> Consider the case of a materialized view
> {code}
> SELECT sales.*, product.*, time_by_day.*
> FROM sales
> JOIN product USING (product_id)
> JOIN time_by_day USING (time_id)
> {code}
> that corresponds to a Druid table
> {noformat}
> sales_product_time(
> product_id int not null,
> time_id int not null,
> units int not null,
> the_year int not null,
> the_quarter int not null,
> the_month int not null,
> the_timestamp timestamp not null,
> product_name varchar(20) not null)
> {noformat}
> And suppose we have the following check constraints:
> * {{CHECK the_year = EXTRACT(YEAR FROM the_timestamp)}}
> * {{CHECK the_month = EXTRACT(MONTH FROM the_timestamp)}}
> Given a query
> {code}
> SELECT product_id, count(*)
> FROM sales
> JOIN product USING (product_id)
> JOIN time_by_day USING (time_id)
> WHERE the_year = 2016
> AND the_month IN (4, 5, 6)
> {code}
> we would like to transform it into the following query to be run against
> Druid:
> {code}
> SELECT product_id, count(*)
> FROM sales_product_time
> WHERE the_timestamp BETWEEN '2016-04-01' AND '2016-06-30'
> {code}
> Druid can handle timestamp ranges (or disjoint sets of ranges) very
> efficiently.
> I believe we can write a rule that knows the check constraints and also knows
> the properties of the {{EXTRACT}} function:
> 1. Apply check constraints to convert {{WHERE year = ...}} to {{WHERE
> EXTRACT(YEAR FROM the_timestamp) = ...}}, etc.
> 2. {{EXTRACT(YEAR FROM ...)}} is monotonic, therefore we can deduce the range
> of the_timestamp values such that {{EXTRACT(YEAR FROM the_timestamp)}}
> returns 2016.
> 3. Then we need to use the fact that {{EXTRACT(MONTH FROM the_timestamp)}} is
> monotonic if {{the_timestamp}} is bounded within a particular year.
> 4. And we need to merge month ranges somehow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1283) Nullability incorrectly assigned in SqlTypeFactory.leastRestrictiveSqlType()
[ https://issues.apache.org/jira/browse/CALCITE-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15468989#comment-15468989 ] Julian Hyde commented on CALCITE-1283: -- And further manifestations fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/8eca1c9f. > Nullability incorrectly assigned in SqlTypeFactory.leastRestrictiveSqlType() > > > Key: CALCITE-1283 > URL: https://issues.apache.org/jira/browse/CALCITE-1283 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > Fix For: 1.9.0 > > > A minor bug where nullability is not accounting for types that return > type.isNullable() true (only considering types that are NULL). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1370) In SqlKind, add OTHER_DDL to DDL enum set
[
https://issues.apache.org/jira/browse/CALCITE-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-1370.
--
Resolution: Fixed
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/547aa67c. Thanks
for the patch, [~rajeshbabu]!
I also added SET_OPTION as DDL, and added some parser tests. I suggest that you
use isDdl() in parser-extension tests such as those in Phoenix.
> In SqlKind, add OTHER_DDL to DDL enum set
> -
>
> Key: CALCITE-1370
> URL: https://issues.apache.org/jira/browse/CALCITE-1370
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Julian Hyde
> Fix For: 1.9.0
>
> Attachments: CALCITE-1370.patch
>
>
> We need to add OTHER_DDL enum value in SqlKind to DDL enum set to execute DDL
> queries implemented as OTHER_DDL type. Otherwise we are not executing ddl
> queries implemented as OTHER_DDL; instead we are going to validate the
> identifiers used in DDL query to from catalog table and fail with below
> exceptions
> {noformat}
> java.sql.SQLException: Error while executing SQL "create function
> myreverse(VARCHAR) returns VARCHAR as 'org.apache.phoenix.end2end.MyReverse'
> using jar 'hdfs://localhost:51573/hbase/tmpjars/myjar1.jar'": From line 1,
> column 17 to line 1, column 25: Column 'MYREVERSE' not found in any table
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:147)
> at
> org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:199)
> at
> org.apache.phoenix.calcite.BaseCalciteIT$Sql.execute(BaseCalciteIT.java:179)
> at
> org.apache.phoenix.calcite.CalciteDDLIT.testCreateFunction(CalciteDDLIT.java:57)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1,
> column 17 to line 1, column 25: Column 'MYREVERSE' not found in any table
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
>
[jira] [Resolved] (CALCITE-1226) Disable AvaticaSpnegoTest due to intermittent failures
[
https://issues.apache.org/jira/browse/CALCITE-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-1226.
--
Resolution: Fixed
Fix Version/s: avatica-1.9.0
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/bf03cd9d. By
which I mean: the test is disabled; CALCITE-1183 is not fixed.
> Disable AvaticaSpnegoTest due to intermittent failures
> --
>
> Key: CALCITE-1226
> URL: https://issues.apache.org/jira/browse/CALCITE-1226
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
> Fix For: avatica-1.9.0
>
>
> I am getting intermittent failures of
> AvaticaSpnegoTest.testAuthenticatedClient:
> {noformat}
> Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.339 sec <<<
> FAILURE! - in org.apache.calcite.avatica.AvaticaSpnegoTest
> testAuthenticatedClient[1](org.apache.calcite.avatica.AvaticaSpnegoTest)
> Time elapsed: 0.141 sec <<< ERROR!
> java.security.PrivilegedActionException: null
> at
> org.apache.calcite.avatica.remote.AvaticaCommonsHttpClientSpnegoImpl.send(AvaticaCommonsHttpClientSpnegoImpl.java:148)
> at
> org.apache.calcite.avatica.remote.RemoteProtobufService._apply(RemoteProtobufService.java:44)
> at
> org.apache.calcite.avatica.remote.ProtobufService.apply(ProtobufService.java:65)
> at
> org.apache.calcite.avatica.remote.RemoteMeta$13.call(RemoteMeta.java:258)
> at
> org.apache.calcite.avatica.remote.RemoteMeta$13.call(RemoteMeta.java:250)
> at
> org.apache.calcite.avatica.AvaticaConnection.invokeWithRetries(AvaticaConnection.java:714)
> at
> org.apache.calcite.avatica.remote.RemoteMeta.prepareAndExecute(RemoteMeta.java:249)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:613)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:140)
> at
> org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:200)
> at
> org.apache.calcite.avatica.AvaticaSpnegoTest$1.run(AvaticaSpnegoTest.java:204)
> at
> org.apache.calcite.avatica.AvaticaSpnegoTest$1.run(AvaticaSpnegoTest.java:200)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.calcite.avatica.AvaticaSpnegoTest.testAuthenticatedClient(AvaticaSpnegoTest.java:200)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1342) ProjectPusher should use rel factories when creating new rels, e.g. project/filter
[ https://issues.apache.org/jira/browse/CALCITE-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15468909#comment-15468909 ] MinJi Kim commented on CALCITE-1342: Okay, sure. I will make the changes. I will give it a try at my first commit! :) > ProjectPusher should use rel factories when creating new rels, e.g. > project/filter > -- > > Key: CALCITE-1342 > URL: https://issues.apache.org/jira/browse/CALCITE-1342 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > I was playing around with some new ideas in drill, and wanted to use > ProjectPusher, which has a lot of useful utility functions. ProjectPusher > returns new nodes, but they are LogicalProjects/LogicalFilters. It would be > more useful if the user of ProjectPusher could specify the rel factories to > use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1342) ProjectPusher should use rel factories when creating new rels, e.g. project/filter
[
https://issues.apache.org/jira/browse/CALCITE-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15468885#comment-15468885
]
Julian Hyde commented on CALCITE-1342:
--
[~minjikim], I saw you modified the arguments to
{{RelOptUtil.createProject(RelNode, List, List, boolean, ProjectFactory)}} and
was going to suggest that retain a deprecated copy of that method. But then I
saw that [~jcamachorodriguez] only recently created the method, in CALCITE-826.
So we're good.
I believe that {{RelOptUtil.createProject(RelNode, List, boolean,
ProjectFactory)}} is not used, and it has not been released. Can you remove it?
After that, +1. Can you please commit and push to Apache master?
* Be sure to add a 'Close apache/calcite#NNN' line, to automatically close the
PR.
* Don't add ' (MinJi Kim)' at the end of the message - we only do that for
non-committers.
* Please mark this case resolved, and fixed in 1.9.0, after you commit.
> ProjectPusher should use rel factories when creating new rels, e.g.
> project/filter
> --
>
> Key: CALCITE-1342
> URL: https://issues.apache.org/jira/browse/CALCITE-1342
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> I was playing around with some new ideas in drill, and wanted to use
> ProjectPusher, which has a lot of useful utility functions. ProjectPusher
> returns new nodes, but they are LogicalProjects/LogicalFilters. It would be
> more useful if the user of ProjectPusher could specify the rel factories to
> use.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1110) remove or relocate shaded jackson in Avatica
[
https://issues.apache.org/jira/browse/CALCITE-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15468739#comment-15468739
]
MinJi Kim commented on CALCITE-1110:
I am curious about what is being considered to resolve this issue. I am having
similar issue with jackson/fasterxml that is being used in Drill. I have
shaded the jackson packages in Avatica in my local build to move forward with
what I am working on, so if it would help to upload this patch to start a
discussion, I am more than happy to do so. Thanks!
> remove or relocate shaded jackson in Avatica
>
>
> Key: CALCITE-1110
> URL: https://issues.apache.org/jira/browse/CALCITE-1110
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Affects Versions: 1.6.0, 1.5.0
>Reporter: Kai Gülzau
>Assignee: Josh Elser
>Priority: Critical
> Fix For: avatica-1.9.0
>
>
> The avatica jar includes a shaded version of jackson under the original
> package path.
> This shaded version interferes with other jackson versions in the classpath.
> Currently this prevents us from using jackson functionality which is only
> implemented in newer versions.
> https://mail-archives.apache.org/mod_mbox/calcite-dev/201602.mbox/%3C977C7450-18F4-48E2-A970-69B7E3E1BD2C%40apache.org%3E
> {quote}
> Is it reasonable to have a maven profile that uses jackson as “provided”[1]
> rather than shading? This would not be the default — the default would be
> continue to use a shaded version of jackson (relocated to
> org.apache.calcite.jackson, as Josh suggests) — but folks looking to embed
> calcite/avatica in a container might appreciate a lighter weight option.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1370) In SqlKind, add OTHER_DDL to DDL enum set
[
https://issues.apache.org/jira/browse/CALCITE-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467754#comment-15467754
]
Julian Hyde edited comment on CALCITE-1370 at 9/6/16 8:46 PM:
--
I am wondering what we can do to prevent this from happening again. I think
tests in SqlParserTest (and Phoenix's sub-class of that test) should make sure
that the tree is DDL, e.g.
{code}
void testInsert() {
sql("insert into foo values (1)")
.node(not(isDdl()));
}
{code}
What do you think?
was (Author: julianhyde):
I am wondering what we can do to prevent this from happening again. I think
tests in SqlParserTest (and Phoenix's sub-class of that test) should make sure
that the tree is DDL, e.g.
{code}
void testInsert() {
sql("insert into foo values (1)")
.ddl(is(true));
}
{code}
What do you think?
> In SqlKind, add OTHER_DDL to DDL enum set
> -
>
> Key: CALCITE-1370
> URL: https://issues.apache.org/jira/browse/CALCITE-1370
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Julian Hyde
> Fix For: 1.9.0
>
> Attachments: CALCITE-1370.patch
>
>
> We need to add OTHER_DDL enum value in SqlKind to DDL enum set to execute DDL
> queries implemented as OTHER_DDL type. Otherwise we are not executing ddl
> queries implemented as OTHER_DDL; instead we are going to validate the
> identifiers used in DDL query to from catalog table and fail with below
> exceptions
> {noformat}
> java.sql.SQLException: Error while executing SQL "create function
> myreverse(VARCHAR) returns VARCHAR as 'org.apache.phoenix.end2end.MyReverse'
> using jar 'hdfs://localhost:51573/hbase/tmpjars/myjar1.jar'": From line 1,
> column 17 to line 1, column 25: Column 'MYREVERSE' not found in any table
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:147)
> at
> org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:199)
> at
> org.apache.phoenix.calcite.BaseCalciteIT$Sql.execute(BaseCalciteIT.java:179)
> at
> org.apache.phoenix.calcite.CalciteDDLIT.testCreateFunction(CalciteDDLIT.java:57)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by:
[jira] [Updated] (CALCITE-1370) In SqlKind, add OTHER_DDL to DDL enum set
[
https://issues.apache.org/jira/browse/CALCITE-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1370:
-
Summary: In SqlKind, add OTHER_DDL to DDL enum set (was: Add OTHER_DDL
enum value in SqlKind to DDL enum set to execute ddl queries implemented as
OTHER_DDL type)
> In SqlKind, add OTHER_DDL to DDL enum set
> -
>
> Key: CALCITE-1370
> URL: https://issues.apache.org/jira/browse/CALCITE-1370
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Julian Hyde
> Fix For: 1.9.0
>
> Attachments: CALCITE-1370.patch
>
>
> We need to add OTHER_DDL enum value to DDL enum set otherwise we are not
> executing ddl queries implemented as OTHER_DDL instead we are going to
> validate the identifiers used in ddl query to from catalog table and fail
> with below exceptions
> {noformat}
> java.sql.SQLException: Error while executing SQL "create function
> myreverse(VARCHAR) returns VARCHAR as 'org.apache.phoenix.end2end.MyReverse'
> using jar 'hdfs://localhost:51573/hbase/tmpjars/myjar1.jar'": From line 1,
> column 17 to line 1, column 25: Column 'MYREVERSE' not found in any table
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:147)
> at
> org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:199)
> at
> org.apache.phoenix.calcite.BaseCalciteIT$Sql.execute(BaseCalciteIT.java:179)
> at
> org.apache.phoenix.calcite.CalciteDDLIT.testCreateFunction(CalciteDDLIT.java:57)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1,
> column 17 to line 1, column 25: Column 'MYREVERSE' not found in any table
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:405)
> at
[jira] [Updated] (CALCITE-1226) Disable AvaticaSpnegoTest due to intermittent failures
[
https://issues.apache.org/jira/browse/CALCITE-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1226:
-
Summary: Disable AvaticaSpnegoTest due to intermittent failures (was:
Intermittent failures in AvaticaSpnegoTest)
> Disable AvaticaSpnegoTest due to intermittent failures
> --
>
> Key: CALCITE-1226
> URL: https://issues.apache.org/jira/browse/CALCITE-1226
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
>
> I am getting intermittent failures of
> AvaticaSpnegoTest.testAuthenticatedClient:
> {noformat}
> Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.339 sec <<<
> FAILURE! - in org.apache.calcite.avatica.AvaticaSpnegoTest
> testAuthenticatedClient[1](org.apache.calcite.avatica.AvaticaSpnegoTest)
> Time elapsed: 0.141 sec <<< ERROR!
> java.security.PrivilegedActionException: null
> at
> org.apache.calcite.avatica.remote.AvaticaCommonsHttpClientSpnegoImpl.send(AvaticaCommonsHttpClientSpnegoImpl.java:148)
> at
> org.apache.calcite.avatica.remote.RemoteProtobufService._apply(RemoteProtobufService.java:44)
> at
> org.apache.calcite.avatica.remote.ProtobufService.apply(ProtobufService.java:65)
> at
> org.apache.calcite.avatica.remote.RemoteMeta$13.call(RemoteMeta.java:258)
> at
> org.apache.calcite.avatica.remote.RemoteMeta$13.call(RemoteMeta.java:250)
> at
> org.apache.calcite.avatica.AvaticaConnection.invokeWithRetries(AvaticaConnection.java:714)
> at
> org.apache.calcite.avatica.remote.RemoteMeta.prepareAndExecute(RemoteMeta.java:249)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:613)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:140)
> at
> org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:200)
> at
> org.apache.calcite.avatica.AvaticaSpnegoTest$1.run(AvaticaSpnegoTest.java:204)
> at
> org.apache.calcite.avatica.AvaticaSpnegoTest$1.run(AvaticaSpnegoTest.java:200)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.calcite.avatica.AvaticaSpnegoTest.testAuthenticatedClient(AvaticaSpnegoTest.java:200)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1354) Release Avatica 1.9.0
[ https://issues.apache.org/jira/browse/CALCITE-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467965#comment-15467965 ] Josh Elser commented on CALCITE-1354: - Sure. I tagged it with the avatica-1.9.0 FixVersion for now. I'll try to get around to it, but would be happy to review a doc improvement from you too ;) > Release Avatica 1.9.0 > - > > Key: CALCITE-1354 > URL: https://issues.apache.org/jira/browse/CALCITE-1354 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Josh Elser > Fix For: avatica-1.9.0 > > > General issue to track the release (so I can better track downstream projects > waiting on fixes from Avatica to be released). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1352) Clarify documentation for avatica's max_rows_total
[
https://issues.apache.org/jira/browse/CALCITE-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1352:
Fix Version/s: avatica-1.9.0
> Clarify documentation for avatica's max_rows_total
> --
>
> Key: CALCITE-1352
> URL: https://issues.apache.org/jira/browse/CALCITE-1352
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Francis Chuang
>Priority: Minor
> Fix For: avatica-1.9.0
>
>
> The {{max_rows_total}} parameter in the protocol buffer definitions should be
> updated to include more information on values that result in unlimited rows
> being returned.
> When testing against calcite 1.8.0, I observed the following:
> {code}
> -1: Unlimited number of rows
> 0: 0 rows
> 1: 1 row
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1353) first_frame_max_size in an ExecuteRequest should be an int32 in protobuf definitions.
[
https://issues.apache.org/jira/browse/CALCITE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467959#comment-15467959
]
Josh Elser commented on CALCITE-1353:
-
bq. would it make sense to change it to a int32 rather than a uint32?
Yup, exactly. I think the reason that this is a 32bit number instead of 64bit
is because of Java's limit on array length.
bq. That way, if we want all the rows in the first frame, we could set it to -1.
Agreed (with the caveat on maximum number of rows in a {{Frame}}).
> first_frame_max_size in an ExecuteRequest should be an int32 in protobuf
> definitions.
> -
>
> Key: CALCITE-1353
> URL: https://issues.apache.org/jira/browse/CALCITE-1353
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Francis Chuang
>Priority: Minor
> Fix For: avatica-1.9.0
>
>
> In the protobuf definition for {{ExecuteRequest}}, the
> {{first_frame_max_size}} parameter is typed as an {{uint64}}. See
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L130.
> For consistency, it should be an {{int32}}.
> Similar parameters relating to the frame size are all typed as {{int32}}.
> For a {{PrepareAndExecuteRequest}}, {{first_frame_max_size}} is a{{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L78
> For a {{FetchRequest}}, {{frame_max_size}} is a {{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L96
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1369) Display a list of Avatica clients on the website
[ https://issues.apache.org/jira/browse/CALCITE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467949#comment-15467949 ] Josh Elser commented on CALCITE-1369: - +1 I like having all of the Calcite/Avatica docs centralized in the source tree. I like to think (hope, maybe?) that in this "Github era", sending a pull request is nearly as easy as editing a wiki. > Display a list of Avatica clients on the website > > > Key: CALCITE-1369 > URL: https://issues.apache.org/jira/browse/CALCITE-1369 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Francis Chuang >Priority: Minor > > I think it would be really neat to have a well organized list of Avatica > clients on the website. This would make clients much more discoverable and > make Avatica and Calcite much more easier for people to get started with. For > example, Kafka has a wiki page with their clients here: > https://cwiki.apache.org/confluence/display/KAFKA/Clients > 1. Most of the clients currently available (the .NET and python ones) are > currently targeted towards Apache Phoenix. Should we include these clients? > If not, is there a process for reaching out to their maintainers to see if > they are interested in generalising them to target Avatica? > 2. Is there any process for including a client on such a page? Should anyone > be able to add the client, or do we need explicit permission from the > maintainers? > 3. To reduce friction, is it viable to have a wiki page, so that maintainers > can easily add their own clients? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1369) Display a list of Avatica clients on the website
[ https://issues.apache.org/jira/browse/CALCITE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467786#comment-15467786 ] Julian Hyde commented on CALCITE-1369: -- I'm not a huge fan of wikis. To keep the information coherent and up to date, I believe that someone who understands the site structure needs to organize (and periodically re-organize) content. This is achieved by a site authored in markdown, a pull request mechanism, and a committer to take the contribution and if necessary clean it up a bit. Anyone who wants to contribute content can make a pull request on the web site, https://github.com/apache/calcite/tree/master/avatica/site. In this case, I think a section needs to be added to the [main doc page|http://calcite.apache.org/avatica/docs], which corresponds to https://github.com/apache/calcite/blob/master/avatica/site/_docs/index.md. Github allows you to edit pages in-place then create a pull request. > Display a list of Avatica clients on the website > > > Key: CALCITE-1369 > URL: https://issues.apache.org/jira/browse/CALCITE-1369 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Francis Chuang >Priority: Minor > > I think it would be really neat to have a well organized list of Avatica > clients on the website. This would make clients much more discoverable and > make Avatica and Calcite much more easier for people to get started with. For > example, Kafka has a wiki page with their clients here: > https://cwiki.apache.org/confluence/display/KAFKA/Clients > 1. Most of the clients currently available (the .NET and python ones) are > currently targeted towards Apache Phoenix. Should we include these clients? > If not, is there a process for reaching out to their maintainers to see if > they are interested in generalising them to target Avatica? > 2. Is there any process for including a client on such a page? Should anyone > be able to add the client, or do we need explicit permission from the > maintainers? > 3. To reduce friction, is it viable to have a wiki page, so that maintainers > can easily add their own clients? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1370) Add OTHER_DDL enum value in SqlKind to DDL enum set to execute ddl queries implemented as OTHER_DDL type
[
https://issues.apache.org/jira/browse/CALCITE-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467754#comment-15467754
]
Julian Hyde commented on CALCITE-1370:
--
I am wondering what we can do to prevent this from happening again. I think
tests in SqlParserTest (and Phoenix's sub-class of that test) should make sure
that the tree is DDL, e.g.
{code}
void testInsert() {
sql("insert into foo values (1)")
.ddl(is(true));
}
{code}
What do you think?
> Add OTHER_DDL enum value in SqlKind to DDL enum set to execute ddl queries
> implemented as OTHER_DDL type
>
>
> Key: CALCITE-1370
> URL: https://issues.apache.org/jira/browse/CALCITE-1370
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Julian Hyde
> Fix For: 1.9.0
>
> Attachments: CALCITE-1370.patch
>
>
> We need to add OTHER_DDL enum value to DDL enum set otherwise we are not
> executing ddl queries implemented as OTHER_DDL instead we are going to
> validate the identifiers used in ddl query to from catalog table and fail
> with below exceptions
> {noformat}
> java.sql.SQLException: Error while executing SQL "create function
> myreverse(VARCHAR) returns VARCHAR as 'org.apache.phoenix.end2end.MyReverse'
> using jar 'hdfs://localhost:51573/hbase/tmpjars/myjar1.jar'": From line 1,
> column 17 to line 1, column 25: Column 'MYREVERSE' not found in any table
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:147)
> at
> org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:199)
> at
> org.apache.phoenix.calcite.BaseCalciteIT$Sql.execute(BaseCalciteIT.java:179)
> at
> org.apache.phoenix.calcite.CalciteDDLIT.testCreateFunction(CalciteDDLIT.java:57)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1,
> column 17 to line 1, column 25: Column 'MYREVERSE' not found in any table
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
>
[jira] [Created] (CALCITE-1370) Add OTHER_DDL enum value in SqlKind to DDL enum set to execute ddl queries implemented as OTHER_DDL type
Rajeshbabu Chintaguntla created CALCITE-1370:
Summary: Add OTHER_DDL enum value in SqlKind to DDL enum set to
execute ddl queries implemented as OTHER_DDL type
Key: CALCITE-1370
URL: https://issues.apache.org/jira/browse/CALCITE-1370
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Rajeshbabu Chintaguntla
Assignee: Julian Hyde
Fix For: 1.9.0
We need to add OTHER_DDL enum value to DDL enum set otherwise we are not
executing ddl queries implemented as OTHER_DDL instead we are going to validate
the identifiers used in ddl query to from catalog table and fail with below
exceptions
{noformat}
java.sql.SQLException: Error while executing SQL "create function
myreverse(VARCHAR) returns VARCHAR as 'org.apache.phoenix.end2end.MyReverse'
using jar 'hdfs://localhost:51573/hbase/tmpjars/myjar1.jar'": From line 1,
column 17 to line 1, column 25: Column 'MYREVERSE' not found in any table
at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:147)
at
org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:199)
at
org.apache.phoenix.calcite.BaseCalciteIT$Sql.execute(BaseCalciteIT.java:179)
at
org.apache.phoenix.calcite.CalciteDDLIT.testCreateFunction(CalciteDDLIT.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1,
column 17 to line 1, column 25: Column 'MYREVERSE' not found in any table
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:405)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:799)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:784)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4049)
at
org.apache.calcite.sql.validate.EmptyScope.findQualifyingTableName(EmptyScope.java:108)
