[jira] [Resolved] (CALCITE-2730) RelBuilder incorrectly simplifies a filter with duplicate conjunction to empty
[ https://issues.apache.org/jira/browse/CALCITE-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-2730. -- Resolution: Fixed Fixed in [8c7dc786|http://git-wip-us.apache.org/repos/asf/calcite/commit/8c7dc786]; thanks for the PR, [~zabetak]! > RelBuilder incorrectly simplifies a filter with duplicate conjunction to empty > -- > > Key: CALCITE-2730 > URL: https://issues.apache.org/jira/browse/CALCITE-2730 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: next >Reporter: Stamatis Zampetakis >Assignee: Julian Hyde >Priority: Major > Fix For: 1.18.0 > > > Regression from 1.17. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-1703) Query with BETWEEN or AGGREGATE functions on TIMESTAMP column throws ClassCastException
[ https://issues.apache.org/jira/browse/CALCITE-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16719929#comment-16719929 ] Koji Kawamura commented on CALCITE-1703: I've encountered the same issue. Hi [~Gkairi], are you still working on this? I couldn't find a PR for this on Github. SoI created a PR, I hope I fixed the same way with you.. [~julianhyde] I just submitted a PR. Would you take a look please? Thanks! https://github.com/apache/calcite/pull/971 > Query with BETWEEN or AGGREGATE functions on TIMESTAMP column throws > ClassCastException > --- > > Key: CALCITE-1703 > URL: https://issues.apache.org/jira/browse/CALCITE-1703 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.11.0 > Environment: Any >Reporter: Gangadhar Kairi >Assignee: Julian Hyde >Priority: Major > > Getting below error while executing the query on timestamp columns with > BETWEEN or AGGREGATE function operator. > java.sql.SQLException: Error while executing SQL "select * from "DATE" where > "JOINTIMES" < '2017-03-16 18:04:07.034'": java.sql.Timestamp cannot be cast > to java.lang.Long > 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:156) > at > org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218) > at > org.apache.calcite.test.CsvTest.testTimestampGTCheck(CsvTest.java:617) > 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:498) > 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.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.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at > com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68) > at > com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51) > at > com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237) > at > com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) > 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:498) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147) > Caused by: java.lang.ClassCastException: java.sql.Timestamp cannot be cast to > java.lang.Long > at Baz$1$1.moveNext(Unknown Source) > at > org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:664) > at org.apache.calcite.linq4j.Linq4j.enumeratorIterator(Linq4j.java:98) > at > org.apache.calcite.linq4j.AbstractEnumerable.iterator(AbstractEnumerable.java:33) > at org.apache.calcite.avatica.MetaImpl.createCursor(MetaImpl.java:89) > at > org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:196) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67) > I could able to reproduce this issues in CsvTests. > > Fire a test with query "select * from \"DATE\" where \"JOINTIMES\" BETWEEN '" > + from + "' and '" + to + "'" you will see test failing with excep
[jira] [Commented] (CALCITE-2674) SqlIdentifier same name with built-in function but with escape character should be still resolved as an identifier
[
https://issues.apache.org/jira/browse/CALCITE-2674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16719930#comment-16719930
]
Julian Hyde commented on CALCITE-2674:
--
Looks good... reviewing now.
> SqlIdentifier same name with built-in function but with escape character
> should be still resolved as an identifier
> --
>
> Key: CALCITE-2674
> URL: https://issues.apache.org/jira/browse/CALCITE-2674
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.18.0
>Reporter: Yuzhao Chen
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.18.0
>
>
> Now If user defines table as schema below:
> {code:java}
> create table tt(
> `current_time` int,
> b int);
> {code}
> Then start a query:
> {code:java}
> select `current_time` from tt;
> {code}
> Calcite parser will parse the *current_time* as a normal *SqlIdentifier*,
> then the SqlValidator will recognize it as a builtin function with below code
> snippet:
> {code:java}
> public static SqlCall makeCall(
> SqlOperatorTable opTab,
> SqlIdentifier id) {
> if (id.names.size() == 1) {
> final List list = new ArrayList<>();
> opTab.lookupOperatorOverloads(id, null, SqlSyntax.FUNCTION, list);
> for (SqlOperator operator : list) {
> if (operator.getSyntax() == SqlSyntax.FUNCTION_ID) {
> // Even though this looks like an identifier, it is a
> // actually a call to a function. Construct a fake
> // call to this function, so we can use the regular
> // operator validation.
> return new SqlBasicCall(
> operator,
> SqlNode.EMPTY_ARRAY,
> id.getParserPosition(),
> true,
> null);
> }
> }
> }
> return null;
> }{code}
> While i tried MYSQL and such query can work properly, so is this a bug ?
> Cause if the matched function's return type is same with the column, then the
> query will output wrong results.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2730) RelBuilder incorrectly simplifies a filter with duplicate conjunction to empty
[ https://issues.apache.org/jira/browse/CALCITE-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16719985#comment-16719985 ] Stamatis Zampetakis commented on CALCITE-2730: -- Thanks for the pointers [~julianhyde], [~kgyrtkirk]! > RelBuilder incorrectly simplifies a filter with duplicate conjunction to empty > -- > > Key: CALCITE-2730 > URL: https://issues.apache.org/jira/browse/CALCITE-2730 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: next >Reporter: Stamatis Zampetakis >Assignee: Julian Hyde >Priority: Major > Fix For: 1.18.0 > > > Regression from 1.17. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2703) Reduce code generation and class loading overhead when executing queries in the EnumerableConvention
[ https://issues.apache.org/jira/browse/CALCITE-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16719993#comment-16719993 ] Lai Zhou commented on CALCITE-2703: --- [~julianhyde] [~zabetak] I use calcite(1.17.0) for real-time computation in product environment, is it beneficial for low latency to cache the query plan , not just the instance? > Reduce code generation and class loading overhead when executing queries in > the EnumerableConvention > > > Key: CALCITE-2703 > URL: https://issues.apache.org/jira/browse/CALCITE-2703 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.17.0 >Reporter: Stamatis Zampetakis >Assignee: Julian Hyde >Priority: Major > Labels: performance > Fix For: 1.18.0 > > > The queries using Calcite's EnumerableConvention always end-up generating new > java classes at runtime (using Janino) that are then instantiated using > reflection. This combination of class generation and class loading introduces > a big overhead in query response time. > A quick profiling on our Company's internal test suite consisting in 4000 > tests with roughly 43 SQL queries passing through Calcite we observed > that a big amount of time is spend on code generation and class loading > making the EnumerableInterpretable#toBindable method a performance > bottleneck. > Among the 43 SQL queries there are many duplicates which are going to > lead to the generation of exactly the same code Java. Introducing, a small > cache at the level of EnumerableInterpretable class could avoid generating > and loading the same code over and over again. > A simple implementation based on Guava improved the overall execution time of > the afforementioned test suite by more than 50%. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2703) Reduce code generation and class loading overhead when executing queries in the EnumerableConvention
[ https://issues.apache.org/jira/browse/CALCITE-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16720036#comment-16720036 ] Stamatis Zampetakis commented on CALCITE-2703: -- [~hhlai1990], as it is the case for this optimization it can be beneficial depending on the query workload. If you have big queries with many joins that happen to appear very often it can be beneficial. On the other hand, if the queries are very simple or if they don't appear often it will not bring much benefit, rather the opposite. > Reduce code generation and class loading overhead when executing queries in > the EnumerableConvention > > > Key: CALCITE-2703 > URL: https://issues.apache.org/jira/browse/CALCITE-2703 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.17.0 >Reporter: Stamatis Zampetakis >Assignee: Julian Hyde >Priority: Major > Labels: performance > Fix For: 1.18.0 > > > The queries using Calcite's EnumerableConvention always end-up generating new > java classes at runtime (using Janino) that are then instantiated using > reflection. This combination of class generation and class loading introduces > a big overhead in query response time. > A quick profiling on our Company's internal test suite consisting in 4000 > tests with roughly 43 SQL queries passing through Calcite we observed > that a big amount of time is spend on code generation and class loading > making the EnumerableInterpretable#toBindable method a performance > bottleneck. > Among the 43 SQL queries there are many duplicates which are going to > lead to the generation of exactly the same code Java. Introducing, a small > cache at the level of EnumerableInterpretable class could avoid generating > and loading the same code over and over again. > A simple implementation based on Guava improved the overall execution time of > the afforementioned test suite by more than 50%. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2703) Reduce code generation and class loading overhead when executing queries in the EnumerableConvention
[ https://issues.apache.org/jira/browse/CALCITE-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16720050#comment-16720050 ] Lai Zhou commented on CALCITE-2703: --- [~zabetak]， in fact， we use calcite to execute a lot of 'hive etl sql' which are big queries for online machine-learning. we extended the native enummerable implementation of calcite to support HiveOperator. I think it will be great if we can cache more thing(maybe the whole query plan) for the same sql . I think it's a common and typical use case . > Reduce code generation and class loading overhead when executing queries in > the EnumerableConvention > > > Key: CALCITE-2703 > URL: https://issues.apache.org/jira/browse/CALCITE-2703 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.17.0 >Reporter: Stamatis Zampetakis >Assignee: Julian Hyde >Priority: Major > Labels: performance > Fix For: 1.18.0 > > > The queries using Calcite's EnumerableConvention always end-up generating new > java classes at runtime (using Janino) that are then instantiated using > reflection. This combination of class generation and class loading introduces > a big overhead in query response time. > A quick profiling on our Company's internal test suite consisting in 4000 > tests with roughly 43 SQL queries passing through Calcite we observed > that a big amount of time is spend on code generation and class loading > making the EnumerableInterpretable#toBindable method a performance > bottleneck. > Among the 43 SQL queries there are many duplicates which are going to > lead to the generation of exactly the same code Java. Introducing, a small > cache at the level of EnumerableInterpretable class could avoid generating > and loading the same code over and over again. > A simple implementation based on Guava improved the overall execution time of > the afforementioned test suite by more than 50%. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2703) Reduce code generation and class loading overhead when executing queries in the EnumerableConvention
[ https://issues.apache.org/jira/browse/CALCITE-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16720057#comment-16720057 ] Stamatis Zampetakis commented on CALCITE-2703: -- [~hhlai1990], I think it is doable but I believe it will be complimentary to this cache so I would suggest to open a new Jira about it. > Reduce code generation and class loading overhead when executing queries in > the EnumerableConvention > > > Key: CALCITE-2703 > URL: https://issues.apache.org/jira/browse/CALCITE-2703 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.17.0 >Reporter: Stamatis Zampetakis >Assignee: Julian Hyde >Priority: Major > Labels: performance > Fix For: 1.18.0 > > > The queries using Calcite's EnumerableConvention always end-up generating new > java classes at runtime (using Janino) that are then instantiated using > reflection. This combination of class generation and class loading introduces > a big overhead in query response time. > A quick profiling on our Company's internal test suite consisting in 4000 > tests with roughly 43 SQL queries passing through Calcite we observed > that a big amount of time is spend on code generation and class loading > making the EnumerableInterpretable#toBindable method a performance > bottleneck. > Among the 43 SQL queries there are many duplicates which are going to > lead to the generation of exactly the same code Java. Introducing, a small > cache at the level of EnumerableInterpretable class could avoid generating > and loading the same code over and over again. > A simple implementation based on Guava improved the overall execution time of > the afforementioned test suite by more than 50%. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2731) RexProgramBuilder makes unsafe simplifications to CASE expressions
[
https://issues.apache.org/jira/browse/CALCITE-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16720291#comment-16720291
]
Zoltan Haindrich commented on CALCITE-2731:
---
[~julianhyde] I've taken a quick look - by running the so far failed ones; I
think there is only one more issue which is most probably a Hive side problem
with types...I will let you know when I know more
> RexProgramBuilder makes unsafe simplifications to CASE expressions
> --
>
> Key: CALCITE-2731
> URL: https://issues.apache.org/jira/browse/CALCITE-2731
> Project: Calcite
> Issue Type: Bug
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
> Fix For: 1.18.0
>
>
> In CALCITE-1413 we were cautious to not simplify
> {code}
> CASE a=0 THEN 0 ELSE 1/a END
> {code}
> and it seemed good; however: {{RexProgramBuilder}} is also invokes simplify -
> but the protection at that point is not able to work, because it sees only
> references:
> {code}
> CASE $1 THEN $2 ELSE $3 END
> {code}
> testcase for conditions.iq:
> {code}
> with ax(s) as (values (1),(0))
> select case when s=0 then false else 100/s > 0 end from ax;
> !ok
> {code}
> resulting exception:
> {code}
> java.lang.AssertionError: Files differ:
> /home/kirk/projects/calcite/core/target/test-classes/sql/surefire/sql/conditions.iq
> /home/kirk/projects/calcite/core/target/test-classes/sql/conditions.iq
> 277a278,326
> > Error while executing command OkCommand [sql: with ax(s) as (values (1),(0))
> > select case when s=0 then false else 100/s > 0 end from ax]
> > java.lang.ArithmeticException: / by zero
> > at Baz$1$1.current(Unknown Source)
> > at
> > org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.next(Linq4j.java:683)
> > at
> > org.apache.calcite.avatica.util.IteratorCursor.next(IteratorCursor.java:46)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2464) Struct types are always not nullable
[
https://issues.apache.org/jira/browse/CALCITE-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16720327#comment-16720327
]
Stamatis Zampetakis commented on CALCITE-2464:
--
{quote}I believe that a ROW value is considered null if and only if all of its
fields are null. (This contradicts what I said above.) Can you please confirm
this?
{quote}
I suppose you are refferring to the IS NULL and IS NOT NULL predicates when
they are applied to a row and yes you are right. I put below the respective
extract from the SQL standard (Table 14 semantics). I guess
the example you presented corresponds to line 3 in the table below.
Let R be the and let V be the value of R.
||Expression||R IS NULL||R IS NOT NULL||NOT R IS NULL||NOT R IS NOT NULL||
|degree 1: null|True|False|False|True|
|degree 1: not null|False|True|True|False|
|degree > 1: all null|True|False|False|True|
|degree > 1: some null|False|False|True|True|
|degree > 1: none null|False|True|True|False|
{quote}If someone declares a column r ROW(x INT NOT NULL, y INT NOT NULL)
should we implicitly add NOT NULL to r?
{quote}
I would say no, because that would forbid setting the column value to null.
{quote}if someone declares r ROW(x INT, y INT) NOT NULL should be implicitly
add NOT NULL to x and y?
{quote}
I would say no, because that would forbid creating a structured type where x or
y is null.
Overall, I don't think it is safe to change the nullability charatecteristic of
the struct based on its attributes neither the opposite.
{quote}
The subject of this case, "Struct types are always not nullable", is ambiguous.
Please change it.
I don't think we need a new method in type factory. You can change the
nullability of the type after it is created.
Can we have a test that executes a query and tests whether a ROW column is
null? E.g. "WHERE address IS NULL", or "WHERE address IS NOT NULL". Also a DDL
test in server's table.iq.
{quote}
OK, for the above.
> Struct types are always not nullable
>
>
> Key: CALCITE-2464
> URL: https://issues.apache.org/jira/browse/CALCITE-2464
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Stamatis Zampetakis
>Assignee: Julian Hyde
>Priority: Major
>
> Struct types are always not nullable. This can lead to bugs in many parts of
> Calcite (e.g., expression simplification, optimization, code generation) that
> are considering the nullability of a RelDataType.
> The method
> [isNullable|https://github.com/apache/calcite/blob/3c6b5ec759caadabb67f09d7a4963cc7d9386d0c/core/src/main/java/org/apache/calcite/rel/type/RelRecordType.java#L55]
> in the RelRecordType, which is used to represent a structured type, always
> returns false. The nullability of the RelRecordType should be a parameter in
> the constructor as it is the case for various other RelDataTypes.
> Additionally, the data type cache should also take into account the
> nullability of the type in order to return a correct equivalent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2464) Struct types are always not nullable
[
https://issues.apache.org/jira/browse/CALCITE-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16720327#comment-16720327
]
Stamatis Zampetakis edited comment on CALCITE-2464 at 12/13/18 3:49 PM:
Indeed, the section that you found gives a nice explanation. Thanks for sharing!
{quote}I believe that a ROW value is considered null if and only if all of its
fields are null. (This contradicts what I said above.) Can you please confirm
this?
{quote}
I suppose you are refferring to the IS NULL and IS NOT NULL predicates when
they are applied to a row and yes you are right. I put below the respective
extract from the SQL standard (Table 14 semantics). I guess
the example you presented corresponds to line 3 in the table below.
Let R be the and let V be the value of R.
||Expression||R IS NULL||R IS NOT NULL||NOT R IS NULL||NOT R IS NOT NULL||
|degree 1: null|True|False|False|True|
|degree 1: not null|False|True|True|False|
|degree > 1: all null|True|False|False|True|
|degree > 1: some null|False|False|True|True|
|degree > 1: none null|False|True|True|False|
{quote}If someone declares a column r ROW(x INT NOT NULL, y INT NOT NULL)
should we implicitly add NOT NULL to r?
{quote}
I would say no, because that would forbid setting the column value to null.
{quote}if someone declares r ROW(x INT, y INT) NOT NULL should be implicitly
add NOT NULL to x and y?
{quote}
I would say no, because that would forbid creating a structured type where x or
y is null.
Overall, I don't think it is safe to change the nullability charatecteristic of
the struct based on its attributes neither the opposite.
{quote}
The subject of this case, "Struct types are always not nullable", is ambiguous.
Please change it.
I don't think we need a new method in type factory. You can change the
nullability of the type after it is created.
Can we have a test that executes a query and tests whether a ROW column is
null? E.g. "WHERE address IS NULL", or "WHERE address IS NOT NULL". Also a DDL
test in server's table.iq.
{quote}
OK, for the above.
was (Author: zabetak):
{quote}I believe that a ROW value is considered null if and only if all of its
fields are null. (This contradicts what I said above.) Can you please confirm
this?
{quote}
I suppose you are refferring to the IS NULL and IS NOT NULL predicates when
they are applied to a row and yes you are right. I put below the respective
extract from the SQL standard (Table 14 semantics). I guess
the example you presented corresponds to line 3 in the table below.
Let R be the and let V be the value of R.
||Expression||R IS NULL||R IS NOT NULL||NOT R IS NULL||NOT R IS NOT NULL||
|degree 1: null|True|False|False|True|
|degree 1: not null|False|True|True|False|
|degree > 1: all null|True|False|False|True|
|degree > 1: some null|False|False|True|True|
|degree > 1: none null|False|True|True|False|
{quote}If someone declares a column r ROW(x INT NOT NULL, y INT NOT NULL)
should we implicitly add NOT NULL to r?
{quote}
I would say no, because that would forbid setting the column value to null.
{quote}if someone declares r ROW(x INT, y INT) NOT NULL should be implicitly
add NOT NULL to x and y?
{quote}
I would say no, because that would forbid creating a structured type where x or
y is null.
Overall, I don't think it is safe to change the nullability charatecteristic of
the struct based on its attributes neither the opposite.
{quote}
The subject of this case, "Struct types are always not nullable", is ambiguous.
Please change it.
I don't think we need a new method in type factory. You can change the
nullability of the type after it is created.
Can we have a test that executes a query and tests whether a ROW column is
null? E.g. "WHERE address IS NULL", or "WHERE address IS NOT NULL". Also a DDL
test in server's table.iq.
{quote}
OK, for the above.
> Struct types are always not nullable
>
>
> Key: CALCITE-2464
> URL: https://issues.apache.org/jira/browse/CALCITE-2464
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Stamatis Zampetakis
>Assignee: Julian Hyde
>Priority: Major
>
> Struct types are always not nullable. This can lead to bugs in many parts of
> Calcite (e.g., expression simplification, optimization, code generation) that
> are considering the nullability of a RelDataType.
> The method
> [isNullable|https://github.com/apache/calcite/blob/3c6b5ec759caadabb67f09d7a4963cc7d9386d0c/core/src/main/java/org/apache/calcite/rel/type/RelRecordType.java#L55]
> in the RelRecordType, which is used to represent a structured type, always
> returns false. The nullability of the RelRecordType should be a parameter in
> the constructor as it is the case for various other Re
[jira] [Updated] (CALCITE-2464) Allow to set nullability for columns of structured types
[ https://issues.apache.org/jira/browse/CALCITE-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-2464: - Summary: Allow to set nullability for columns of structured types (was: Struct types are always not nullable) > Allow to set nullability for columns of structured types > > > Key: CALCITE-2464 > URL: https://issues.apache.org/jira/browse/CALCITE-2464 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: Stamatis Zampetakis >Assignee: Julian Hyde >Priority: Major > > Struct types are always not nullable. This can lead to bugs in many parts of > Calcite (e.g., expression simplification, optimization, code generation) that > are considering the nullability of a RelDataType. > The method > [isNullable|https://github.com/apache/calcite/blob/3c6b5ec759caadabb67f09d7a4963cc7d9386d0c/core/src/main/java/org/apache/calcite/rel/type/RelRecordType.java#L55] > in the RelRecordType, which is used to represent a structured type, always > returns false. The nullability of the RelRecordType should be a parameter in > the constructor as it is the case for various other RelDataTypes. > Additionally, the data type cache should also take into account the > nullability of the type in order to return a correct equivalent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2464) Allow to set nullability for columns of structured types
[
https://issues.apache.org/jira/browse/CALCITE-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16720599#comment-16720599
]
Julian Hyde commented on CALCITE-2464:
--
Here's a SQL DDL example would might help crystalize this for many people:
{code}
CREATE TYPE ZipCode AS (
zip5 CHAR(5) NOT NULL,
zip4 CHAR(4));
CREATE TYPE Address AS (
street VARCHAR(20) NOT NULL,
street2 VARCHAR(20),
zip ZipCode NOT NULL,
city VARCHAR(20) NOT NULL);
CREATE TABLE Contacts (
name VARCHAR(20) NOT NULL,
address Address NOT NULL);
{code}
There is a similar example in
[server/.../type.iq|https://github.com/apache/calcite/blob/master/server/src/test/resources/sql/type.iq],
which seems to have NOT NULL working, so please highlight what would be the
new functionality.
> Allow to set nullability for columns of structured types
>
>
> Key: CALCITE-2464
> URL: https://issues.apache.org/jira/browse/CALCITE-2464
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Stamatis Zampetakis
>Assignee: Julian Hyde
>Priority: Major
>
> Struct types are always not nullable. This can lead to bugs in many parts of
> Calcite (e.g., expression simplification, optimization, code generation) that
> are considering the nullability of a RelDataType.
> The method
> [isNullable|https://github.com/apache/calcite/blob/3c6b5ec759caadabb67f09d7a4963cc7d9386d0c/core/src/main/java/org/apache/calcite/rel/type/RelRecordType.java#L55]
> in the RelRecordType, which is used to represent a structured type, always
> returns false. The nullability of the RelRecordType should be a parameter in
> the constructor as it is the case for various other RelDataTypes.
> Additionally, the data type cache should also take into account the
> nullability of the type in order to return a correct equivalent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2673) Default implementation of SqlDialect should not support pushing all functions
[
https://issues.apache.org/jira/browse/CALCITE-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16720715#comment-16720715
]
Jesus Camacho Rodriguez commented on CALCITE-2673:
--
[~julianhyde], I have a small addendum for this issue to add the {{ROW}}
operator, which I miss in the first patch. I was wondering whether it is OK to
push right now. Otherwise, if you are working on the next RC, I will just
create a new issue and push it after the release. Please, let me know.
> Default implementation of SqlDialect should not support pushing all functions
> -
>
> Key: CALCITE-2673
> URL: https://issues.apache.org/jira/browse/CALCITE-2673
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Major
> Fix For: 1.18.0
>
>
> SqlDialect contains a 'supportsFunction' that can be used by rules to know
> whether a certain function is supported in the given dialect, e.g., to choose
> whether to push a Filter expression to JDBC, etc.
> The default implementation of 'supportsFunction' always returns true.
> I believe a better idea would be to support in the default implementation for
> the method the most common SQL functions. Then each dialect can override that
> behavior and expand/limit the supported functions, e.g., JethroDataDialect
> already does that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2673) Default implementation of SqlDialect should not support pushing all functions
[ https://issues.apache.org/jira/browse/CALCITE-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16720729#comment-16720729 ] Julian Hyde commented on CALCITE-2673: -- As long as the tests and javadoc pass on all JDKs and it has a unit test, and there is no chance of breaking anything else, you can push it. > Default implementation of SqlDialect should not support pushing all functions > - > > Key: CALCITE-2673 > URL: https://issues.apache.org/jira/browse/CALCITE-2673 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jesus Camacho Rodriguez >Assignee: Jesus Camacho Rodriguez >Priority: Major > Fix For: 1.18.0 > > > SqlDialect contains a 'supportsFunction' that can be used by rules to know > whether a certain function is supported in the given dialect, e.g., to choose > whether to push a Filter expression to JDBC, etc. > The default implementation of 'supportsFunction' always returns true. > I believe a better idea would be to support in the default implementation for > the method the most common SQL functions. Then each dialect can override that > behavior and expand/limit the supported functions, e.g., JethroDataDialect > already does that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2721) Support parsing of DOT + MEMBER_FUNCTION
[
https://issues.apache.org/jira/browse/CALCITE-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16720733#comment-16720733
]
Julian Hyde commented on CALCITE-2721:
--
Yes, that is what I am referring to. At this point, all we should do is the
parser (i.e. add a test to SqlParserTest and make it pass). Validation and
execution could be done later.
The parser cannot distinguish between {{mySchema.mySubSchema.myFunction()}} and
{{myTable.myColumn.myField.myMethod()}} (because it does not resolve names) so
the parse tree for both of these examples would look similar.
When implementing this, make sure you don't conflict with CALCITE-2674, which
has a PR almost ready to commit.
> Support parsing of DOT + MEMBER_FUNCTION
>
>
> Key: CALCITE-2721
> URL: https://issues.apache.org/jira/browse/CALCITE-2721
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Rong Rong
>Assignee: Julian Hyde
>Priority: Major
> Attachments: 6_17_Method_invocation.png
>
>
> Support parsing of + parsing Similar to
> {panel:title=Example}
> {{SELECT t.complex_col}}*{{.member_func()}}* {{FROM tbl;}}
> {panel}
> For more details please see: [Member
> Function|https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_8001.htm#i2126584]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-1703) Query with BETWEEN or AGGREGATE functions on TIMESTAMP column throws ClassCastException
[
https://issues.apache.org/jira/browse/CALCITE-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16720734#comment-16720734
]
Julian Hyde commented on CALCITE-1703:
--
Could you please add a test case?
> Query with BETWEEN or AGGREGATE functions on TIMESTAMP column throws
> ClassCastException
> ---
>
> Key: CALCITE-1703
> URL: https://issues.apache.org/jira/browse/CALCITE-1703
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.11.0
> Environment: Any
>Reporter: Gangadhar Kairi
>Assignee: Julian Hyde
>Priority: Major
>
> Getting below error while executing the query on timestamp columns with
> BETWEEN or AGGREGATE function operator.
> {noformat}
> java.sql.SQLException: Error while executing SQL "select * from "DATE" where
> "JOINTIMES" < '2017-03-16 18:04:07.034'": java.sql.Timestamp cannot be cast
> to java.lang.Long
> 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:156)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218)
> at
> org.apache.calcite.test.CsvTest.testTimestampGTCheck(CsvTest.java:617)
> 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:498)
> 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.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.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> 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:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.ClassCastException: java.sql.Timestamp cannot be cast to
> java.lang.Long
> at Baz$1$1.moveNext(Unknown Source)
> at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:664)
> at org.apache.calcite.linq4j.Linq4j.enumeratorIterator(Linq4j.java:98)
> at
> org.apache.calcite.linq4j.AbstractEnumerable.iterator(AbstractEnumerable.java:33)
> at org.apache.calcite.avatica.MetaImpl.createCursor(MetaImpl.java:89)
> at
> org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:196)
> at
> org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67)
> {noformat}
> I could able to reproduce this issues in CsvTests.
>
> Fire a test with query "select * from \"DATE\" where \"JOINTIMES\" BETWEEN '"
> + from + "' and '" + to + "'" you will see test failing with exception.
> Root cause and fix:
> Timestamp datatype needs to be handled in the same way as the Date datatype.
> In {{RexToLixTranslator.convert()}} method and in
> {{PhysTypeImpl.fieldReference()}} method.
--
This message was sent by Atlas
[jira] [Updated] (CALCITE-1703) Query with BETWEEN or AGGREGATE functions on TIMESTAMP column throws ClassCastException
[
https://issues.apache.org/jira/browse/CALCITE-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1703:
-
Description:
Getting below error while executing the query on timestamp columns with BETWEEN
or AGGREGATE function operator.
{noformat}
java.sql.SQLException: Error while executing SQL "select * from "DATE" where
"JOINTIMES" < '2017-03-16 18:04:07.034'": java.sql.Timestamp cannot be cast to
java.lang.Long
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:156)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218)
at
org.apache.calcite.test.CsvTest.testTimestampGTCheck(CsvTest.java:617)
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:498)
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.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.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
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:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
Caused by: java.lang.ClassCastException: java.sql.Timestamp cannot be cast to
java.lang.Long
at Baz$1$1.moveNext(Unknown Source)
at
org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:664)
at org.apache.calcite.linq4j.Linq4j.enumeratorIterator(Linq4j.java:98)
at
org.apache.calcite.linq4j.AbstractEnumerable.iterator(AbstractEnumerable.java:33)
at org.apache.calcite.avatica.MetaImpl.createCursor(MetaImpl.java:89)
at
org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:196)
at
org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67)
{noformat}
I could able to reproduce this issues in CsvTests.
Fire a test with query "select * from \"DATE\" where \"JOINTIMES\" BETWEEN '" +
from + "' and '" + to + "'" you will see test failing with exception.
Root cause and fix:
Timestamp datatype needs to be handled in the same way as the Date datatype.
In {{RexToLixTranslator.convert()}} method and in
{{PhysTypeImpl.fieldReference()}} method.
was:
Getting below error while executing the query on timestamp columns with BETWEEN
or AGGREGATE function operator.
java.sql.SQLException: Error while executing SQL "select * from "DATE" where
"JOINTIMES" < '2017-03-16 18:04:07.034'": java.sql.Timestamp cannot be cast to
java.lang.Long
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:156)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218)
at
org.apache.calcite.test.CsvTest.testTimestampGTCheck(CsvTest.java:617
[jira] [Commented] (CALCITE-2673) Default implementation of SqlDialect should not support pushing all functions
[
https://issues.apache.org/jira/browse/CALCITE-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16720799#comment-16720799
]
Jesus Camacho Rodriguez commented on CALCITE-2673:
--
I will push the addendum; it is not risky since
{{SqlFunction.supportsFunction}} is not used in Calcite. It is quite bad that
it is not used and it does not have any tests... I have created CALCITE-2740 to
follow up on this.
> Default implementation of SqlDialect should not support pushing all functions
> -
>
> Key: CALCITE-2673
> URL: https://issues.apache.org/jira/browse/CALCITE-2673
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Major
> Fix For: 1.18.0
>
>
> SqlDialect contains a 'supportsFunction' that can be used by rules to know
> whether a certain function is supported in the given dialect, e.g., to choose
> whether to push a Filter expression to JDBC, etc.
> The default implementation of 'supportsFunction' always returns true.
> I believe a better idea would be to support in the default implementation for
> the method the most common SQL functions. Then each dialect can override that
> behavior and expand/limit the supported functions, e.g., JethroDataDialect
> already does that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2735) support load data of dml statement
[
https://issues.apache.org/jira/browse/CALCITE-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16720800#comment-16720800
]
Julian Hyde commented on CALCITE-2735:
--
Your facts are slightly incorrect. While MySQL supports {{LOAD DATA}} in SQL,
Oracle does not support {{LOAD DATA}} in SQL, only in
[SQLLoader|https://stackoverflow.com/questions/8953110/load-data-infile-equivalent-in-oracle]
scripts.
There's no official policy for what we should accept into the DDL parser, but I
think we should be aiming for a common subset - that is, commands supported by
two or three unrelated databases - and I don't think this feature passes that
threshold. Even if we don't add it to our DDL parser, it should be fairly
straightforward to add it to your own variant of the parser, using the fmpp
templates we provide. If it is not straightforward, we should extend the
template system.
> support load data of dml statement
> --
>
> Key: CALCITE-2735
> URL: https://issues.apache.org/jira/browse/CALCITE-2735
> Project: Calcite
> Issue Type: Improvement
> Components: server
>Affects Versions: 1.17.0, 1.18.0
>Reporter: ambition
>Assignee: Julian Hyde
>Priority: Minor
> Fix For: 1.18.0
>
>
> support load data statement, like mysql or apache hive, dml sql is:
> {code:java}
> LOAD DATA [LOCAL] INFILE 'filePath' [OVERWRITE] INTO TABLE tableName
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2740) Add tests for SqlFunction.supportsFunction method
[ https://issues.apache.org/jira/browse/CALCITE-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesus Camacho Rodriguez updated CALCITE-2740: - Description: Method is used in Hive, but it is not used by Calcite. At the very least, we should add some unit tests to check that the method is working as expected. (was: Method is used in Hive, but it is not used by Calcite at all. At the very least, we should add some unit tests to check that the method is working as expected.) > Add tests for SqlFunction.supportsFunction method > - > > Key: CALCITE-2740 > URL: https://issues.apache.org/jira/browse/CALCITE-2740 > Project: Calcite > Issue Type: Test > Components: jdbc-adapter >Reporter: Jesus Camacho Rodriguez >Assignee: Jesus Camacho Rodriguez >Priority: Major > > Method is used in Hive, but it is not used by Calcite. At the very least, we > should add some unit tests to check that the method is working as expected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2740) Add tests for SqlFunction.supportsFunction method
Jesus Camacho Rodriguez created CALCITE-2740: Summary: Add tests for SqlFunction.supportsFunction method Key: CALCITE-2740 URL: https://issues.apache.org/jira/browse/CALCITE-2740 Project: Calcite Issue Type: Test Components: jdbc-adapter Reporter: Jesus Camacho Rodriguez Assignee: Jesus Camacho Rodriguez Method is used in Hive, but it is not used by Calcite at all. At the very least, we should add some unit tests to check that the method is working as expected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2740) Add tests for SqlFunction.supportsFunction method
[
https://issues.apache.org/jira/browse/CALCITE-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16720801#comment-16720801
]
Jesus Camacho Rodriguez commented on CALCITE-2740:
--
For more context, method is used in Hive by {{JDBCAbstractSplitFilterRule}},
which may (partially) push down computation to JDBC sources depending on
whether the expressions are supported or not.
> Add tests for SqlFunction.supportsFunction method
> -
>
> Key: CALCITE-2740
> URL: https://issues.apache.org/jira/browse/CALCITE-2740
> Project: Calcite
> Issue Type: Test
> Components: jdbc-adapter
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Major
>
> Method is used in Hive, but it is not used by Calcite. At the very least, we
> should add some unit tests to check that the method is working as expected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2673) Default implementation of SqlDialect should not support pushing all functions
[ https://issues.apache.org/jira/browse/CALCITE-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16720806#comment-16720806 ] Jesus Camacho Rodriguez commented on CALCITE-2673: -- Addendum in [f362785e1|http://git-wip-us.apache.org/repos/asf/calcite/commit/f362785e1]. > Default implementation of SqlDialect should not support pushing all functions > - > > Key: CALCITE-2673 > URL: https://issues.apache.org/jira/browse/CALCITE-2673 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jesus Camacho Rodriguez >Assignee: Jesus Camacho Rodriguez >Priority: Major > Fix For: 1.18.0 > > > SqlDialect contains a 'supportsFunction' that can be used by rules to know > whether a certain function is supported in the given dialect, e.g., to choose > whether to push a Filter expression to JDBC, etc. > The default implementation of 'supportsFunction' always returns true. > I believe a better idea would be to support in the default implementation for > the method the most common SQL functions. Then each dialect can override that > behavior and expand/limit the supported functions, e.g., JethroDataDialect > already does that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CALCITE-2735) support load data of dml statement
[
https://issues.apache.org/jira/browse/CALCITE-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ambition closed CALCITE-2735.
-
Resolution: Fixed
> support load data of dml statement
> --
>
> Key: CALCITE-2735
> URL: https://issues.apache.org/jira/browse/CALCITE-2735
> Project: Calcite
> Issue Type: Improvement
> Components: server
>Affects Versions: 1.17.0, 1.18.0
>Reporter: ambition
>Assignee: Julian Hyde
>Priority: Minor
> Fix For: 1.18.0
>
>
> support load data statement, like mysql or apache hive, dml sql is:
> {code:java}
> LOAD DATA [LOCAL] INFILE 'filePath' [OVERWRITE] INTO TABLE tableName
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2735) support load data of dml statement
[
https://issues.apache.org/jira/browse/CALCITE-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16720820#comment-16720820
]
ambition commented on CALCITE-2735:
---
ok
> support load data of dml statement
> --
>
> Key: CALCITE-2735
> URL: https://issues.apache.org/jira/browse/CALCITE-2735
> Project: Calcite
> Issue Type: Improvement
> Components: server
>Affects Versions: 1.17.0, 1.18.0
>Reporter: ambition
>Assignee: Julian Hyde
>Priority: Minor
> Fix For: 1.18.0
>
>
> support load data statement, like mysql or apache hive, dml sql is:
> {code:java}
> LOAD DATA [LOCAL] INFILE 'filePath' [OVERWRITE] INTO TABLE tableName
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-1703) Query with BETWEEN or AGGREGATE functions on TIMESTAMP column throws ClassCastException
[
https://issues.apache.org/jira/browse/CALCITE-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16720834#comment-16720834
]
Koji Kawamura commented on CALCITE-1703:
[~julianhyde] I tried to add a test to CsvTest as written in this JIRA
description, but using CsvTest doesn't reproduce the issue any longer. Because
CALCITE-1754 added rel type conversion from Java types to BasicSqlTypes.
I encountered this issue particularly with Apache NiFi QueryRecord processor,
which uses java.sql.Timestamp rel type.
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/queryrecord/FlowFileTable.java#L206
I'm going to add another test class using a custom table using Java types.
> Query with BETWEEN or AGGREGATE functions on TIMESTAMP column throws
> ClassCastException
> ---
>
> Key: CALCITE-1703
> URL: https://issues.apache.org/jira/browse/CALCITE-1703
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.11.0
> Environment: Any
>Reporter: Gangadhar Kairi
>Assignee: Julian Hyde
>Priority: Major
>
> Getting below error while executing the query on timestamp columns with
> BETWEEN or AGGREGATE function operator.
> {noformat}
> java.sql.SQLException: Error while executing SQL "select * from "DATE" where
> "JOINTIMES" < '2017-03-16 18:04:07.034'": java.sql.Timestamp cannot be cast
> to java.lang.Long
> 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:156)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218)
> at
> org.apache.calcite.test.CsvTest.testTimestampGTCheck(CsvTest.java:617)
> 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:498)
> 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.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.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> 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:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.ClassCastException: java.sql.Timestamp cannot be cast to
> java.lang.Long
> at Baz$1$1.moveNext(Unknown Source)
> at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:664)
> at org.apache.calcite.linq4j.Linq4j.enumeratorIterator(Linq4j.java:98)
> at
> org.apache.calcite.linq4j.AbstractEnumerable.iterator(AbstractEnumerable.java:33)
> at org.apache.calcite.avatica.MetaImpl.createCursor(MetaImpl.java:89)
> at
> org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResul
