[jira] [Commented] (CALCITE-1453) Support ANY type with binary compare / arithmetic operators
[ https://issues.apache.org/jira/browse/CALCITE-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604114#comment-15604114 ] Jungtaek Lim commented on CALCITE-1453: --- [~julianhyde] Addressed your comments (both pull request and issue). Could you take a look again? Thanks in advance! > Support ANY type with binary compare / arithmetic operators > --- > > Key: CALCITE-1453 > URL: https://issues.apache.org/jira/browse/CALCITE-1453 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jungtaek Lim >Assignee: Jungtaek Lim > > Currently Calcite doesn't support applying binary compare / arithmetic > operators with ANY type. One of example is > CollectionTypeTest.testAccessNestedMapWithAnyTypeWithoutCast(). Without > explicit casting, it can't find the matching backup method, and complaining > there's no SqlFunctions.eq(Object, int). > There seems to several ways to resolve this, but at least we don't want to > make operator backup method for every combination of types. Needs to avoid > this approach. > When we're addressing this by having backup method, since we don't know the > runtime type for ANY type, even if we succeed to call backup method with > (Object, Object) parameters, two types can be different. This is OK for other > types, but not Number types. This should be well cared, too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1453) Support ANY type with binary compare / arithmetic operators
[ https://issues.apache.org/jira/browse/CALCITE-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15603750#comment-15603750 ] Jungtaek Lim commented on CALCITE-1453: --- Just found out we have RexCall, so we can check actual Rel type, instead of relying on Java type on Expression. That may be not issue at all. (I'm referring BinaryImplementor.implement()) > Support ANY type with binary compare / arithmetic operators > --- > > Key: CALCITE-1453 > URL: https://issues.apache.org/jira/browse/CALCITE-1453 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jungtaek Lim >Assignee: Jungtaek Lim > > Currently Calcite doesn't support applying binary compare / arithmetic > operators with ANY type. One of example is > CollectionTypeTest.testAccessNestedMapWithAnyTypeWithoutCast(). Without > explicit casting, it can't find the matching backup method, and complaining > there's no SqlFunctions.eq(Object, int). > There seems to several ways to resolve this, but at least we don't want to > make operator backup method for every combination of types. Needs to avoid > this approach. > When we're addressing this by having backup method, since we don't know the > runtime type for ANY type, even if we succeed to call backup method with > (Object, Object) parameters, two types can be different. This is OK for other > types, but not Number types. This should be well cared, too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1453) Support ANY type with binary compare / arithmetic operators
[
https://issues.apache.org/jira/browse/CALCITE-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15603739#comment-15603739
]
Julian Hyde commented on CALCITE-1453:
--
{quote} One thing to make it clear: Do we have any chance to receive Object
type while it's not rel type of ANY?{quote}
If there were no code generation bugs, probably not. But there are (and likely
always will be) code generation bugs.
> Support ANY type with binary compare / arithmetic operators
> ---
>
> Key: CALCITE-1453
> URL: https://issues.apache.org/jira/browse/CALCITE-1453
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jungtaek Lim
>Assignee: Jungtaek Lim
>
> Currently Calcite doesn't support applying binary compare / arithmetic
> operators with ANY type. One of example is
> CollectionTypeTest.testAccessNestedMapWithAnyTypeWithoutCast(). Without
> explicit casting, it can't find the matching backup method, and complaining
> there's no SqlFunctions.eq(Object, int).
> There seems to several ways to resolve this, but at least we don't want to
> make operator backup method for every combination of types. Needs to avoid
> this approach.
> When we're addressing this by having backup method, since we don't know the
> runtime type for ANY type, even if we succeed to call backup method with
> (Object, Object) parameters, two types can be different. This is OK for other
> types, but not Number types. This should be well cared, too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1453) Support ANY type with binary compare / arithmetic operators
[ https://issues.apache.org/jira/browse/CALCITE-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15603678#comment-15603678 ] Jungtaek Lim commented on CALCITE-1453: --- Yes agreed. Let me add some tests on SqlFunctionsTest. And I also think we can append postfix "Any" to backupMethod and call it as you suggested. ANY type with not yet supported backupMethod will fail, but that seems more clear on avoiding false-positive. One thing to make it clear: Do we have any chance to receive Object type while it's not rel type of ANY? > Support ANY type with binary compare / arithmetic operators > --- > > Key: CALCITE-1453 > URL: https://issues.apache.org/jira/browse/CALCITE-1453 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jungtaek Lim >Assignee: Jungtaek Lim > > Currently Calcite doesn't support applying binary compare / arithmetic > operators with ANY type. One of example is > CollectionTypeTest.testAccessNestedMapWithAnyTypeWithoutCast(). Without > explicit casting, it can't find the matching backup method, and complaining > there's no SqlFunctions.eq(Object, int). > There seems to several ways to resolve this, but at least we don't want to > make operator backup method for every combination of types. Needs to avoid > this approach. > When we're addressing this by having backup method, since we don't know the > runtime type for ANY type, even if we succeed to call backup method with > (Object, Object) parameters, two types can be different. This is OK for other > types, but not Number types. This should be well cared, too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1466) Support for UNSIGNED types of int,long,float etc. in type system
[
https://issues.apache.org/jira/browse/CALCITE-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15603543#comment-15603543
]
Julian Hyde edited comment on CALCITE-1466 at 10/24/16 11:33 PM:
-
I support the idea of adding UNSIGNED INTEGER etc. to Avatica's type system,
but note that these types have different ranges than the unsigned types in
Phoenix. For instance, UNSIGNED INTEGER has a range of 0 ... 2^31 - 1
(4,294,967,295) in MySQL but a range of 0 ... 2^31 - 1 (2,147,483,647) in
Phoenix. So, to solve Phoenix's problem we would need a different set of types.
If I'm reading the [ODBC
headers|https://apt-browse.org/browse/ubuntu/trusty/main/i386/libiodbc2-dev/3.52.7-3.1/file/usr/include/sqlext.h]
correctly, the type codes are as follows:
{noformat}
SQL name C name CodeMin
Max
= == ==
==
BIGINTSQL_C_BIGINT -5 -9,223,372,036,854,775,808
9,223,372,036,854,775,807
INTEGER SQL_C_LONG4 -2,147,483,648
2,147,483,647
SMALLINT SQL_C_SHORT 5-32,768
32,767
TINYINT SQL_C_TINYINT-6 -128
127
UNSIGNED BIGINT SQL_C_UBIGINT -27 0
18,446,744,073,709,551,615
UNSIGNED INTEGER SQL_C_ULONG -18 0
4,294,967,295
UNSIGNED SMALLINT SQL_C_USHORT-17 0
65,536
UNSIGNED TINYINT SQL_C_UTINYINT -28 0
256
{noformat}
was (Author: julianhyde):
I support the idea of adding UNSIGNED INTEGER etc. to Avatica's type system,
but note that these types have different ranges than the unsigned types in
Phoenix. For instance, UNSIGNED INTEGER has a range of 0 ... 2^31 - 1
(4,294,967,295) in MySQL but a range of 0 ... 2^31 - 1 (2,147,483,647) in
Phoenix. So, to solve Phoenix's problem we would need a different set of types.
If I'm reading the [ODBC
headers|https://apt-browse.org/browse/ubuntu/trusty/main/i386/libiodbc2-dev/3.52.7-3.1/file/usr/include/sqlext.h]
correctly, the type codes are as follows:
{noformat}
SQL name C name Code
= ==
BIGINTSQL_C_BIGINT -5
INTEGER SQL_C_LONG4
SMALLINT SQL_C_SHORT 5
TINYINT SQL_C_TINYINT-6
UNSIGNED BIGINT SQL_C_UBIGINT -27
UNSIGNED INTEGER SQL_C_ULONG -18
UNSIGNED SMALLINT SQL_C_USHORT-17
UNSIGNED TINYINT SQL_C_UTINYINT -28
{noformat}
> Support for UNSIGNED types of int,long,float etc. in type system
>
>
> Key: CALCITE-1466
> URL: https://issues.apache.org/jira/browse/CALCITE-1466
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Rajeshbabu Chintaguntla
>
> There are some data bases like MySQL supporting unsigned data types. Apache
> Phoenix also supports them. Would be great to add them to calcite as well.
> http://dev.mysql.com/doc/refman/5.7/en/integer-types.html
--
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=15603557#comment-15603557
]
Francis Chuang commented on CALCITE-1353:
-
Perhaps it might also be a good time to do an audit on all the fields so we can
deprecate/introduce the new fields in 1.10.
> 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.10.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-1466) Support for UNSIGNED types of int,long,float etc. in type system
[
https://issues.apache.org/jira/browse/CALCITE-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15603543#comment-15603543
]
Julian Hyde commented on CALCITE-1466:
--
I support the idea of adding UNSIGNED INTEGER etc. to Avatica's type system,
but note that these types have different ranges than the unsigned types in
Phoenix. For instance, UNSIGNED INTEGER has a range of 0 ... 2^31 - 1
(4,294,967,295) in MySQL but a range of 0 ... 2^31 - 1 (2,147,483,647) in
Phoenix. So, to solve Phoenix's problem we would need a different set of types.
If I'm reading the [ODBC
headers|https://apt-browse.org/browse/ubuntu/trusty/main/i386/libiodbc2-dev/3.52.7-3.1/file/usr/include/sqlext.h]
correctly, the type codes are as follows:
{noformat}
SQL name C name Code
= ==
BIGINTSQL_C_BIGINT -5
INTEGER SQL_C_LONG4
SMALLINT SQL_C_SHORT 5
TINYINT SQL_C_TINYINT-6
UNSIGNED BIGINT SQL_C_UBIGINT -27
UNSIGNED INTEGER SQL_C_ULONG -18
UNSIGNED SMALLINT SQL_C_USHORT-17
UNSIGNED TINYINT SQL_C_UTINYINT -28
{noformat}
> Support for UNSIGNED types of int,long,float etc. in type system
>
>
> Key: CALCITE-1466
> URL: https://issues.apache.org/jira/browse/CALCITE-1466
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Rajeshbabu Chintaguntla
>
> There are some data bases like MySQL supporting unsigned data types. Apache
> Phoenix also supports them. Would be great to add them to calcite as well.
> http://dev.mysql.com/doc/refman/5.7/en/integer-types.html
--
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=15603499#comment-15603499
]
Francis Chuang commented on CALCITE-1353:
-
Good point, [~elserj]. Go does have uint64 and int32 types. With the Go driver,
this change would require a minor update to the client. The code currently
casts the int32 to a uint64, so if it is set to -1, it overflows to
18446744073709551615, which should be pretty much "all" rows. Changing it to
an int32 would require me to remove the cast from int32 to uint64, but I
believe it is much better than relying on the overflowing behaviour.
For backwards compatibility, I think the idea of introducing a new field is
probably the best way forward. In this case, do you have a proposed name for
the field?
I also think it would be nice to incorporate changes to maxRowCount into this
(totally missed that!), but again, if we want a new field, we need to decide on
a suitable name.
> 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.10.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] [Resolved] (CALCITE-1465) Store constants as a derived field in RelOptPredicateList
[
https://issues.apache.org/jira/browse/CALCITE-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-1465.
--
Resolution: Fixed
Fix Version/s: 1.11.0
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/0f36aec7.
> Store constants as a derived field in RelOptPredicateList
> -
>
> Key: CALCITE-1465
> URL: https://issues.apache.org/jira/browse/CALCITE-1465
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
> Fix For: 1.11.0
>
>
> I propose that we compute predicate constants when we create a
> {{RelOptPredicateList}}, and store them in an immutable field {{constantMap}}.
> Currently, any rule that wishes to detect constants by aliasing (e.g. if we
> know {{x = 5}} and {{x = y}} then we can deduce {{y = 5}}) must start with a
> {{RelOptPredicateList}} (from the metadata supplier) and call the
> {{ReduceExpressionsRule.predicateConstants}} method. This method is called
> many times: in the current Calcite suite 1,201 instances of
> {{RelOptPredicateList}} are created and {{predicateConstants}} is called
> 82,670 times.
> Pre-computing would use a little extra memory but reduce the method calls by
> ~68x.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1461) Hard-coded class name in JaninoRelMetadataProvider breaks shading
[
https://issues.apache.org/jira/browse/CALCITE-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1461:
-
Summary: Hard-coded class name in JaninoRelMetadataProvider breaks shading
(was: Hard coded class name in JaninoRelMetadataProvider breaks shading)
> Hard-coded class name in JaninoRelMetadataProvider breaks shading
> -
>
> Key: CALCITE-1461
> URL: https://issues.apache.org/jira/browse/CALCITE-1461
> Project: Calcite
> Issue Type: Bug
>Reporter: Jark Wu
>Assignee: Julian Hyde
> Fix For: 1.11.0
>
>
> In {{JaninoRelMetadataProvider.load3}}, the generated class string contains
> some hard coded Calcite's classes, such as
> {{org.apache.calcite.rel.metadata.MetadataDef}}. After shading Calcite, the
> MetadataDef can not be found in the shaded classes. And a compile error will
> be thrown.
> So it's better to use {{MetadataDef.class.getName()}} to replace the hard
> code string.
> I'm appreciate to make a PR if you want.
--
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=15603425#comment-15603425
]
Julian Hyde commented on CALCITE-1353:
--
Thanks [~francischuang]. Looks good to me; [~elserj], does this meet your
requirements for backwards compatibility? If so I'll commit and include in the
1.9 release.
> 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.10.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-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=15603383#comment-15603383
]
Francis Chuang commented on CALCITE-1353:
-
See https://github.com/apache/calcite/pull/319
> 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.10.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] [Updated] (CALCITE-1390) Avatica JDBC driver wrongly modifies Properties object
[
https://issues.apache.org/jira/browse/CALCITE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1390:
-
Summary: Avatica JDBC driver wrongly modifies Properties object (was:
Properties object is modified by Avatica JDBC Driver)
> Avatica JDBC driver wrongly modifies Properties object
> --
>
> Key: CALCITE-1390
> URL: https://issues.apache.org/jira/browse/CALCITE-1390
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Prabhjyot Singh
>Assignee: Josh Elser
> Fix For: avatica-1.9.0
>
>
> Creating this JIRA from mail thread
> https://lists.apache.org/thread.html/5029f1f09c95a76b6e60a0f80e6f145dedf0b51cfdc08b964fb3b060@%3Cuser.phoenix.apache.org%3E
> I'm using DriverManager.getConnection(url, properties) using following
> properties
> {code}
> url -> "jdbc:phoenix:thin:url=http://prabhu-3.novalocal:8765;serialization
> =PROTOBUF"
> {code}
> {code}
> properties ->
> 0 = {java.util.Hashtable$Entry@1491} "user" -> "phoenixuser"
> 1 = {java.util.Hashtable$Entry@1492} "password" ->
> 2 = {java.util.Hashtable$Entry@1493} "url" ->
> "jdbc:phoenix:thin:url=http://prabhu-3.novalocal:8765;serialization
> =PROTOBUF"
> 3 = {java.util.Hashtable$Entry@1494} "hbase.client.retries.number" -> "4"
> 4 = {java.util.Hashtable$Entry@1495} "driver" ->
> "org.apache.phoenix.jdbc.PhoenixDriver"
> {code}
> With the above propert/setting/config it returns a connection to the URL
> specified, but it also modifies my properties object to following
> {code}
> properties ->
> 0 = {java.util.Hashtable$Entry@2361} "serialization" -> "PROTOBUF"
> 1 = {java.util.Hashtable$Entry@2362} "user" -> "phoenixuser"
> 2 = {java.util.Hashtable$Entry@2363} "password" ->
> *3 = {java.util.Hashtable$Entry@2364} "url" ->
> "http://prabhu-3.novalocal:8765 "*
> 4 = {java.util.Hashtable$Entry@2365} "hbase.client.retries.number" -> "4"
> 5 = {java.util.Hashtable$Entry@2366} "driver" ->
> "org.apache.phoenix.jdbc.PhoenixDriver"
> {code}
> The above only happens if I'm using *thin-client*. Is this the expected
> behaviour ?
> I plan to use this "properties" object after getting the connection for
> something else.
> Also, I'm using following in my maven dependency
> "org.apache.phoenix:phoenix-server-client:4.7.0-HBase-1.1"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1210) Cassandra uuid filtering does not work
[
https://issues.apache.org/jira/browse/CALCITE-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1210:
-
Fix Version/s: 1.8.0
> Cassandra uuid filtering does not work
> --
>
> Key: CALCITE-1210
> URL: https://issues.apache.org/jira/browse/CALCITE-1210
> Project: Calcite
> Issue Type: Bug
> Components: cassandra
>Affects Versions: 1.7.0
>Reporter: Dan Di Spaltro
>Assignee: Michael Mior
>Priority: Minor
> Fix For: 1.8.0
>
>
> It looks like the syntax for sending a uuid to cassandra is something like
> this
> {code}
> select key from timetest where key=7daecb80-29b0-11e3-92ec-e291eb9d325e
> {code}
> Which is a bare identifier, unquoted. So any filtering based on uuid's
> doesn't work. You get something like this:
> {code}
> Caused by: com.datastax.driver.core.exceptions.InvalidQueryException: Invalid
> STRING constant (a594f989-8e73-4145-b9fb-83bd565f9995) for "tweet_id" of type
> uuid`
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1441) DOUBLE is returned as BigDecimal with JSON serialization
[ https://issues.apache.org/jira/browse/CALCITE-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1441: - Fix Version/s: (was: 1.11.0) avatica-1.9.0 > DOUBLE is returned as BigDecimal with JSON serialization > > > Key: CALCITE-1441 > URL: https://issues.apache.org/jira/browse/CALCITE-1441 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: avatica-1.9.0 > > > Noticed in my testing for ARRAY support: > Serializing a DOUBLE results in Jackson using BigDecimal. This type is > directly returned to the user instead of being correctly returned as a Double > per the JDBC 4.1 specification, Table B-1: "JDBC Types Mapped to Java Types" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1149) Derive AVG’s return type by a customizable policy
[ https://issues.apache.org/jira/browse/CALCITE-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1149: - Fix Version/s: 1.8.0 > Derive AVG’s return type by a customizable policy > - > > Key: CALCITE-1149 > URL: https://issues.apache.org/jira/browse/CALCITE-1149 > Project: Calcite > Issue Type: Improvement >Reporter: Jacques Nadeau >Assignee: Jacques Nadeau > Fix For: 1.8.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1025) Add support for HTTP Basic auth (for proxies) in Avatica HTTP Client
[ https://issues.apache.org/jira/browse/CALCITE-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1025: - Fix Version/s: avatica-1.8.0 > Add support for HTTP Basic auth (for proxies) in Avatica HTTP Client > > > Key: CALCITE-1025 > URL: https://issues.apache.org/jira/browse/CALCITE-1025 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Phillip Rhodes >Assignee: Phillip Rhodes > Fix For: avatica-1.8.0 > > Attachments: AvaticaConnection.patch, Driver.patch, > RemoteService.patch, http_auth_patch.patch, patch_against_1.2.0.patch > > > Avatica serves as the base for the Phoenix "thin" JDBC driver, and supports a > JSON over HTTP protocol. Being that it is HTTP, it would be desirable to > support standard HTTP mechanisms like HTTP BASIC authentication, which is > required by some proxy servers (for example, Knox). > In particular, I've been working on deploying Phoenix behind Knox with Knox > mediating JDBC access using the "thin" driver based on Avatica. In order to > make this work, I had to make a small change to Avatica in order to take the > supplied credentials and construct an Authorization header, and add it to the > HTTP request. > I have made this change and verified that it works, and would like to propose > merging it into the Avatica source. I have two versions, one made against > HEAD and another which is a backport to an older version of Avatica (turns > out this was needed for the specific environment we were deploying in). > It is a fairly small change, totaling about 10-15 lines of code, and - as far > as I can tell - should be totally non-invasive to existing users of Avatica. > Basically I just add the HTTP Authorization header IF a username/password > combo is present, and do nothing otherwise. If it is desired, we could also > wrap this code in a parameter based on a query string parameter or something. > Maybe "enableProxyAuth=true" or something along those lines. > I'll attach the actual modified code shortly, but in the meantime wanted to > start a discussion around this proposed change. I have run this by some > people inside HortonWorks and they are in favor of implementing this so that > it can become part of HDP. Being able to use Knox (or, in theory, any other > proxy server) to mediate JDBC access to Phoenix seems to be a desirable > thing. Thoughts? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1193) NullPointerException when trying to execute prepared statement using avatica
[
https://issues.apache.org/jira/browse/CALCITE-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1193:
-
Fix Version/s: avatica-1.8.0
> NullPointerException when trying to execute prepared statement using avatica
>
>
> Key: CALCITE-1193
> URL: https://issues.apache.org/jira/browse/CALCITE-1193
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.7.1
> Environment: Phoenix 4.7.0 and Phoenix 4.8.0-SNAPSHOT
>Reporter: Francis Chuang
>Assignee: Josh Elser
> Fix For: avatica-1.8.0
>
>
> To reproduce, set the phoenix query server to use JSON for serialization:
> 1. Create a table called {{my_table}} and seed it using SquirrelSQL:
> {code}
> CREATE TABLE my_table (k BIGINT PRIMARY KEY, v VARCHAR) TRANSACTIONAL=true
> UPSERT INTO my_table VALUES (1,'A')
> UPSERT INTO my_table VALUES (2,'B')
> UPSERT INTO my_table VALUES (3,'C')
> UPSERT INTO my_table VALUES (4,'D')
> {code}
> Send the following requests using curl:
> {code}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request":
> "openConnection","connectionId": "my-conn"}'
> {"response":"openConnection","rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request": "prepare","connectionId":
> "my-conn","sql": "SELECT * FROM my_table","maxRowCount": 1}'
> {"response":"prepare","statement":{"connectionId":"my-conn","id":36,"signature":{"columns":[{"ordinal":0,"autoIncrement":false,"caseSensitive":false,"searchable":true,"currency":false,"nullable":0,"signed":true,"displaySize":40,"label":"K","columnName":"K","schemaName":"","precision":0,"scale":0,"tableName":"MY_TABLE","catalogName":"","type":{"type":"scalar","id":-5,"name":"BIGINT","rep":"PRIMITIVE_LONG"},"readOnly":true,"writable":false,"definitelyWritable":false,"columnClassName":"java.lang.Long"},{"ordinal":1,"autoIncrement":false,"caseSensitive":false,"searchable":true,"currency":false,"nullable":1,"signed":false,"displaySize":40,"label":"V","columnName":"V","schemaName":"","precision":0,"scale":0,"tableName":"MY_TABLE","catalogName":"","type":{"type":"scalar","id":12,"name":"VARCHAR","rep":"STRING"},"readOnly":true,"writable":false,"definitelyWritable":false,"columnClassName":"java.lang.String"}],"sql":"SELECT
> * FROM
> my_table","parameters":[],"cursorFactory":{"style":"LIST","clazz":null,"fieldNames":null},"statementType":null}},"rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request": "execute","statementHandle":
> {"connectionId": "my-conn","id": 36},"maxRowCount": 1}'
> {"response":"error","exceptions":["java.lang.NullPointerException\n\tat
> org.apache.calcite.avatica.MetaImpl.checkParameterValueHasNull(MetaImpl.java:952)\n\tat
> org.apache.calcite.avatica.jdbc.JdbcMeta.execute(JdbcMeta.java:781)\n\tat
> org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:233)\n\tat
>
> org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:950)\n\tat
>
> org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:928)\n\tat
>
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:102)\n\tat
>
> org.apache.calcite.avatica.remote.JsonHandler.apply(JsonHandler.java:43)\n\tat
>
> org.apache.calcite.avatica.server.AvaticaJsonHandler.handle(AvaticaJsonHandler.java:73)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:497)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:245)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)\n\tat
>
> java.lang.Thread.run(Thread.java:745)\n"],"errorMessage":"NullPointerException:
> (null exception
> message)","errorCode":-1,"sqlState":"0","severity":"UNKNOWN","rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
> {code}
> Notice that the server throws a NPE when trying to execute the prepared
> statement.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1212) Cassandra Projections throw an NPE on a join with another non-cassandra table
[
https://issues.apache.org/jira/browse/CALCITE-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1212:
-
Fix Version/s: 1.8.0
> Cassandra Projections throw an NPE on a join with another non-cassandra table
> -
>
> Key: CALCITE-1212
> URL: https://issues.apache.org/jira/browse/CALCITE-1212
> Project: Calcite
> Issue Type: Bug
> Components: cassandra
>Affects Versions: 1.7.0
>Reporter: Dan Di Spaltro
>Assignee: Michael Mior
>Priority: Minor
> Fix For: 1.8.0
>
>
> Okay, I am really note entirely sure where to begin describing this, since it
> involves a lot of what I don't fully understand but Ill list out some of the
> observations and maybe that might help.
> I have a Jdbc table named assets, it has a field named {{name}} that is
> {{VARCHAR}}. If I attempt to do a join like so
> {code}
> select *
> from core.assets
> join twissandra.tweets
> on core.assets.name = twissandra.tweets.username
> {code}
> I get an exception like this
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.calcite.adapter.cassandra.CassandraTable.query(CassandraTable.java:121)
> at
> org.apache.calcite.adapter.cassandra.CassandraTable$CassandraQueryable.query(CassandraTable.java:206)
> at Baz.bind(Baz.java:6)
> at
> org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:327)
> {code}
> It looks like it's related to the {{username}} field potentially not having
> the same type {{CHAR}} vs {{VARCHAR}} so it gets flagged as a new field? This
> [code|https://github.com/apache/calcite/blob/91887366c40310f2435b2677ac0d9616bed842cb/cassandra/src/main/java/org/apache/calcite/adapter/cassandra/CassandraProject.java#L57-L77]
> seems to be adding four fields instead of five the additional {{username4}}
> which causes the NPE.
> I have the output of the code generation here if that helps
> {code}
> /* 1 */ org.apache.calcite.DataContext root;
> /* 2 */
> /* 3 */ public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root0) {
> /* 4 */ root = root0;
> /* 5 */ final java.util.List predicates = java.util.Arrays.asList(new
> String[] {});
> /* 6 */ final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> ((org.apache.calcite.adapter.cassandra.CassandraTable.CassandraQueryable)
> org.apache.calcite.schema.Schemas.queryable(root,
> root.getRootSchema().getSubSchema("twissandra"), java.lang.Object[].class,
> "tweets")).query(java.util.Arrays.asList(new org.apache.calcite.util.Pair[] {
> /* 7 */ new org.apache.calcite.util.Pair(
> /* 8 */ "tweet_id",
> /* 9 */ java.lang.String.class),
> /* 10 */ new org.apache.calcite.util.Pair(
> /* 11 */ "body",
> /* 12 */ java.lang.String.class),
> /* 13 */ new org.apache.calcite.util.Pair(
> /* 14 */ "tenant_id",
> /* 15 */ java.lang.String.class),
> /* 16 */ new org.apache.calcite.util.Pair(
> /* 17 */ "username",
> /* 18 */ java.lang.String.class),
> /* 19 */ new org.apache.calcite.util.Pair(
> /* 20 */ "username4",
> /* 21 */ java.lang.String.class)}), predicates, predicates,
> null).join(org.apache.calcite.runtime.ResultSetEnumerable.of(((org.apache.calcite.adapter.jdbc.JdbcSchema)
>
> root.getRootSchema().getSubSchema("core").unwrap(org.apache.calcite.adapter.jdbc.JdbcSchema.class)).getDataSource(),
> "SELECT *\nFROM \"assets\"", new
> org.apache.calcite.linq4j.function.Function1() {
> /* 22 */ public org.apache.calcite.linq4j.function.Function0 apply(final
> java.sql.ResultSet resultSet) {
> /* 23 */ return new org.apache.calcite.linq4j.function.Function0() {
> /* 24 */ public Object apply() {
> /* 25 */ try {
> /* 26 */ final Object[] values = new Object[4];
> /* 27 */ values[0] = resultSet.getObject(1);
> /* 28 */ values[1] = resultSet.getObject(2);
> /* 29 */ values[2] = resultSet.getObject(3);
> /* 30 */ values[3] = resultSet.getObject(4);
> /* 31 */ return values;
> /* 32 */ } catch (java.sql.SQLException e) {
> /* 33 */ throw new RuntimeException(
> /* 34 */ e);
> /* 35 */ }
> /* 36 */ }
> /* 37 */ }
> /* 38 */ ;
> /* 39 */ }
> /* 40 */ public Object apply(final Object resultSet) {
> /* 41 */ return apply(
> /* 42 */ (java.sql.ResultSet) resultSet);
> /* 43 */ }
> /* 44 */ }
> /* 45 */ ), new org.apache.calcite.linq4j.function.Function1() {
> /* 46 */ public String apply(Object[] v1) {
> /* 47 */ return v1[4] == null ?
[jira] [Updated] (CALCITE-1203) Update to newest stable github-pages gem
[ https://issues.apache.org/jira/browse/CALCITE-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1203: - Fix Version/s: 1.8.0 > Update to newest stable github-pages gem > > > Key: CALCITE-1203 > URL: https://issues.apache.org/jira/browse/CALCITE-1203 > Project: Calcite > Issue Type: Improvement > Components: site >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Trivial > Fix For: 1.8.0 > > > According to https://pages.github.com/versions/, the current version of the > github-pages Gem is 69 (I presently have 43 in my Gemfile.lock). > To make sure we're all building consistent versions of the website, we should > specify a version of the github-pages gem (which will also ensure that we > have consistent versions of Jekyll in use). > We'll probably have to make a glance over the website to make sure everything > is still rendered correctly after the version update. > If that goes well, we should remove the explicit jekyll gem dependency in > Gemfile and just add a specific github-pages version instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1203) Update to newest stable github-pages gem
[ https://issues.apache.org/jira/browse/CALCITE-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1203: - Component/s: site > Update to newest stable github-pages gem > > > Key: CALCITE-1203 > URL: https://issues.apache.org/jira/browse/CALCITE-1203 > Project: Calcite > Issue Type: Improvement > Components: site >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Trivial > Fix For: 1.8.0 > > > According to https://pages.github.com/versions/, the current version of the > github-pages Gem is 69 (I presently have 43 in my Gemfile.lock). > To make sure we're all building consistent versions of the website, we should > specify a version of the github-pages gem (which will also ensure that we > have consistent versions of Jekyll in use). > We'll probably have to make a glance over the website to make sure everything > is still rendered correctly after the version update. > If that goes well, we should remove the explicit jekyll gem dependency in > Gemfile and just add a specific github-pages version instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1215) Missing method override in CassandraTable
[ https://issues.apache.org/jira/browse/CALCITE-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1215: - Fix Version/s: 1.8.0 > Missing method override in CassandraTable > - > > Key: CALCITE-1215 > URL: https://issues.apache.org/jira/browse/CALCITE-1215 > Project: Calcite > Issue Type: Bug > Components: cassandra >Reporter: Michael Mior >Assignee: Michael Mior > Fix For: 1.8.0 > > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.2:compile (default-compile) > on project calcite-cassandra: Compilation failure > [ERROR] > /Users/jni/work/optiq/cassandra/src/main/java/org/apache/calcite/adapter/cassandra/CassandraTable.java:[151,41] > is not > abstract and does not override abstract method remove() in java.util.Iterator > [ERROR] -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the > command > [ERROR] mvn -rf :calcite-cassandra -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1211) limit > 7 on the Cassandra Adapter switches to EnumerableLimit rule
[
https://issues.apache.org/jira/browse/CALCITE-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1211:
-
Fix Version/s: 1.8.0
> limit > 7 on the Cassandra Adapter switches to EnumerableLimit rule
> ---
>
> Key: CALCITE-1211
> URL: https://issues.apache.org/jira/browse/CALCITE-1211
> Project: Calcite
> Issue Type: Bug
> Components: cassandra
>Affects Versions: 1.7.0
>Reporter: Dan Di Spaltro
>Assignee: Michael Mior
>Priority: Minor
> Fix For: 1.8.0
>
>
> I copied the testProject query because I was noticing a {{EnumerableLimit}}
> showing up on explains when a limit was higher than `1`. So I narrowed it
> down to 7, anything above 7 and the plan looks like this
> {code}
> Plan after physical tweaks: EnumerableLimit(fetch=[8]): rowcount = 8.0,
> cumulative cost = {112.5 rows, 122.0 cpu, 0.0 io}, id = 2083
> CassandraToEnumerableConverter: rowcount = 15.0, cumulative cost = {104.5
> rows, 114.0 cpu, 0.0 io}, id = 2081
> CassandraProject(tweet_id=[$2]): rowcount = 15.0, cumulative cost =
> {103.0 rows, 112.5 cpu, 0.0 io}, id = 2079
> CassandraFilter(condition=[=(CAST($0):CHAR(8) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary", '!PUBLIC!')]): rowcount =
> 15.0, cumulative cost = {101.5 rows, 111.0 cpu, 0.0 io}, id = 2077
> CassandraTableScan(table=[[twissandra, userline]]): rowcount = 100.0,
> cumulative cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 1915
> {code}
> anything {{7}} or below looks like this
> {code}
> CassandraToEnumerableConverter: rowcount = 7.0, cumulative cost =
> {111.07282262603232 rows, 112.75 cpu, 0.0 io}, id = 2257
> CassandraProject(tweet_id=[$2]): rowcount = 7.0, cumulative cost =
> {110.37282262603232 rows, 112.05 cpu, 0.0 io}, id = 2255
> CassandraSort(fetch=[7]): rowcount = 7.0, cumulative cost =
> {109.67282262603231 rows, 111.35 cpu, 0.0 io}, id = 2253
> CassandraFilter(condition=[=(CAST($0):CHAR(8) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary", '!PUBLIC!')]): rowcount =
> 15.0, cumulative cost = {101.5 rows, 111.0 cpu, 0.0 io}, id = 2251
> CassandraTableScan(table=[[twissandra, userline]]): rowcount = 100.0,
> cumulative cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 2089
> {code}
> If I wanted to change that would I alter the cost of the sort rule?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1217) SQL parse error if column named 'value'
[
https://issues.apache.org/jira/browse/CALCITE-1217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1217:
-
Fix Version/s: 1.8.0
> SQL parse error if column named 'value'
> ---
>
> Key: CALCITE-1217
> URL: https://issues.apache.org/jira/browse/CALCITE-1217
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.7.0
>Reporter: Heng Chen
>Assignee: Julian Hyde
> Fix For: 1.8.0
>
>
> {code}
> select t1.a, t2.b, `t2.value` from t1 left join t2 on t1.id=t2.id join
> (select a,b,c from t3) t4 on t2.id=t4.id where t2.b>100
> {code}
> {code}
> Exception in thread "main" org.apache.calcite.sql.parser.SqlParseException:
> Lexical error at line 1, column 20. Encountered: "`" (96), after : ""
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.convertException(SqlParserImpl.java:388)
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.normalizeException(SqlParserImpl.java:119)
> at
> org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:131)
> at org.apache.calcite.sql.parser.SqlParser.parseStmt(SqlParser.java:156)
> at org.apache.calcite.prepare.PlannerImpl.parse(PlannerImpl.java:167)
> at
> com.fenbi.pipe.utils.SqlParserUtils.getDependTables(SqlParserUtils.java:77)
> at com.fenbi.pipe.utils.SqlParserUtils.run(SqlParserUtils.java:72)
> at com.fenbi.pipe.utils.SqlParserUtils.main(SqlParserUtils.java:111)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: org.apache.calcite.sql.parser.impl.TokenMgrError: Lexical error at
> line 1, column 20. Encountered: "`" (96), after : ""
> at
> org.apache.calcite.sql.parser.impl.SqlParserImplTokenManager.getNextToken(SqlParserImplTokenManager.java:14038)
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.jj_scan_token(SqlParserImpl.java:17512)
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.jj_3_81(SqlParserImpl.java:11351)
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.jj_3R_114(SqlParserImpl.java:11343)
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.jj_3R_45(SqlParserImpl.java:11449)
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.jj_3_78(SqlParserImpl.java:11475)
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.jj_2_78(SqlParserImpl.java:6036)
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.SelectList(SqlParserImpl.java:1340)
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.SqlSelect(SqlParserImpl.java:874)
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.LeafQuery(SqlParserImpl.java:578)
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.LeafQueryOrExpr(SqlParserImpl.java:2417)
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.QueryOrExpr(SqlParserImpl.java:2336)
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.OrderedQueryOrExpr(SqlParserImpl.java:496)
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.SqlStmt(SqlParserImpl.java:805)
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.SqlStmtEof(SqlParserImpl.java:831)
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.parseSqlStmtEof(SqlParserImpl.java:178)
> at
> org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:124)
> ... 10 more
> Process finished with exit code 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1169) Memory leak caused by CALCITE-604 and CALCITE-1147
[ https://issues.apache.org/jira/browse/CALCITE-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1169: - Fix Version/s: (was: 1.11.0) 1.8.0 > Memory leak caused by CALCITE-604 and CALCITE-1147 > -- > > Key: CALCITE-1169 > URL: https://issues.apache.org/jira/browse/CALCITE-1169 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.7.0 >Reporter: Maryann Xue >Assignee: Julian Hyde > Fix For: 1.8.0 > > > It might be easier to reproduce this with an IDE environment. If I try > running CalciteIT in Calcite-Phoenix in eclipse, it would usually crash after > the first 3 - 4 test cases because of OOM. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1375) Why "select CONCAT('a','b') from EMPS" won't work?
[
https://issues.apache.org/jira/browse/CALCITE-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1375:
-
Fix Version/s: (was: 1.11.0)
1.9.0
> Why "select CONCAT('a','b') from EMPS" won't work?
> --
>
> Key: CALCITE-1375
> URL: https://issues.apache.org/jira/browse/CALCITE-1375
> Project: Calcite
> Issue Type: Bug
>Reporter: hongbin ma
>Assignee: Julian Hyde
> Fix For: 1.9.0
>
>
> Hi experts,
> I have some confusing observations:
> || query || result ||
> | select QUARTER(DATE'2010-01-02') from EMPS; | OK |
> | select {fn QUARTER(DATE'2010-01-02')} from EMPS; | OK|
> |select {fn CONCAT('a','b')} from EMPS; | OK|
> |select CONCAT('a','b') from EMPS; |FAIL|
> The error message is :
> Error: Error while executing SQL "select CONCAT('a','b') from EMPS": From
> line 1, column 8 to line 1, column 22: No match found for function signature
> CONCAT(, ) (state=,code=0)
> why is CONCAT without function escape failing? is there any reasons behind
> this?
> There're many JDBC escape functions in
> https://calcite.apache.org/docs/reference.html, is there a way to tell which
> can run without the "{fn" prefix?
> I'm using calcite 1.8.0's sqlline under example/csv
> thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1223) sqlline doesn't treat lines beginning with -- as comments
[ https://issues.apache.org/jira/browse/CALCITE-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1223: - Fix Version/s: 1.8.0 > sqlline doesn't treat lines beginning with -- as comments > - > > Key: CALCITE-1223 > URL: https://issues.apache.org/jira/browse/CALCITE-1223 > Project: Calcite > Issue Type: Bug >Reporter: James Taylor >Assignee: Julian Hyde >Priority: Minor > Fix For: 1.8.0 > > > Not sure if this is a bug or done on purpose, but if you execute a script > with sqlline, it doesn't interprets lines beginning with -- as comments. > Should it? I believe that's more expected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1232) AvaticaStatement should fail fast on executeBatch() if no statements are present in the batch
[
https://issues.apache.org/jira/browse/CALCITE-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1232:
-
Fix Version/s: avatica-1.9.0
> AvaticaStatement should fail fast on executeBatch() if no statements are
> present in the batch
> -
>
> Key: CALCITE-1232
> URL: https://issues.apache.org/jira/browse/CALCITE-1232
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.9.0
>
>
> Ran into a little bug. I prepared a batch of updates via a PreparedStatement
> but then accidentally called {{executeBatch()}} on another Statement object
> which was currently in scope. This was causing my test to fail because it
> appeared that there were no updates applied in the returned {{int[]}}.
> We should make {{executeBatch()}} on both {{AvaticaStatement}} and
> {{AvaticaPreparedStatement}} fail with an exception if the current batch is
> empty.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1291) Incorrect formatting from Avatica in sqlline's table outputformat
[
https://issues.apache.org/jira/browse/CALCITE-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1291:
-
Fix Version/s: (was: 1.11.0)
avatica-1.9.0
> Incorrect formatting from Avatica in sqlline's table outputformat
> -
>
> Key: CALCITE-1291
> URL: https://issues.apache.org/jira/browse/CALCITE-1291
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.9.0
>
>
> {noformat}
> 0: jdbc:phoenix:thin:url=http://localhost:876> select * from STR_VIEW;
> +--+--++
> |PK| VAL
> |LONG_VALUE |
> +--+--++
> | ASDFASDFASDFASDFASDFASDFASDFASDFASDFASDFASDFASDF | value1
> | valuevaluevaluevalueva |
> +--+--++
> 1 row selected (0.025 seconds)
> {noformat}
> {noformat}
> 0: jdbc:phoenix:localhost:2181:/hbase-1.2> select * from STR_VIEW;
> +---+-+-+
> |PK | VAL |
> LONG_VALUE |
> +---+-+-+
> | ASDFASDFASDFASDFASDFASDFASDFASDFASDFASDFASDFASDF | value1 |
> valuevaluevaluevaluevaluevaluevaluevaluevaluevalue |
> +---+-+-+
> 1 row selected (0.058 seconds)
> {noformat}
> This is the difference between using Apache Phoenix's avatica client and the
> normal client and sqlline 1.1.9. With {{!outputformat table}} above, we can
> see the difference in these two clients, while {{!outputformat xmlattr}}
> shows the complete (and expected) values.
> It seems like some column metadata is just not being properly sent by PQS (at
> least that's my hunch). The data is present in the results, just not rendered
> properly. I'll have to look into what sqlline pulls for the column width and
> figure out if PQS is sending that properly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1375) Why "select CONCAT('a','b') from EMPS" won't work?
[
https://issues.apache.org/jira/browse/CALCITE-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1375:
-
Fix Version/s: 1.11.0
> Why "select CONCAT('a','b') from EMPS" won't work?
> --
>
> Key: CALCITE-1375
> URL: https://issues.apache.org/jira/browse/CALCITE-1375
> Project: Calcite
> Issue Type: Bug
>Reporter: hongbin ma
>Assignee: Julian Hyde
> Fix For: 1.11.0
>
>
> Hi experts,
> I have some confusing observations:
> || query || result ||
> | select QUARTER(DATE'2010-01-02') from EMPS; | OK |
> | select {fn QUARTER(DATE'2010-01-02')} from EMPS; | OK|
> |select {fn CONCAT('a','b')} from EMPS; | OK|
> |select CONCAT('a','b') from EMPS; |FAIL|
> The error message is :
> Error: Error while executing SQL "select CONCAT('a','b') from EMPS": From
> line 1, column 8 to line 1, column 22: No match found for function signature
> CONCAT(, ) (state=,code=0)
> why is CONCAT without function escape failing? is there any reasons behind
> this?
> There're many JDBC escape functions in
> https://calcite.apache.org/docs/reference.html, is there a way to tell which
> can run without the "{fn" prefix?
> I'm using calcite 1.8.0's sqlline under example/csv
> thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1169) Memory leak caused by CALCITE-604 and CALCITE-1147
[ https://issues.apache.org/jira/browse/CALCITE-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1169: - Fix Version/s: 1.11.0 > Memory leak caused by CALCITE-604 and CALCITE-1147 > -- > > Key: CALCITE-1169 > URL: https://issues.apache.org/jira/browse/CALCITE-1169 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.7.0 >Reporter: Maryann Xue >Assignee: Julian Hyde > Fix For: 1.11.0 > > > It might be easier to reproduce this with an IDE environment. If I try > running CalciteIT in Calcite-Phoenix in eclipse, it would usually crash after > the first 3 - 4 test cases because of OOM. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1291) Incorrect formatting from Avatica in sqlline's table outputformat
[
https://issues.apache.org/jira/browse/CALCITE-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1291:
-
Fix Version/s: 1.11.0
> Incorrect formatting from Avatica in sqlline's table outputformat
> -
>
> Key: CALCITE-1291
> URL: https://issues.apache.org/jira/browse/CALCITE-1291
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: 1.11.0
>
>
> {noformat}
> 0: jdbc:phoenix:thin:url=http://localhost:876> select * from STR_VIEW;
> +--+--++
> |PK| VAL
> |LONG_VALUE |
> +--+--++
> | ASDFASDFASDFASDFASDFASDFASDFASDFASDFASDFASDFASDF | value1
> | valuevaluevaluevalueva |
> +--+--++
> 1 row selected (0.025 seconds)
> {noformat}
> {noformat}
> 0: jdbc:phoenix:localhost:2181:/hbase-1.2> select * from STR_VIEW;
> +---+-+-+
> |PK | VAL |
> LONG_VALUE |
> +---+-+-+
> | ASDFASDFASDFASDFASDFASDFASDFASDFASDFASDFASDFASDF | value1 |
> valuevaluevaluevaluevaluevaluevaluevaluevaluevalue |
> +---+-+-+
> 1 row selected (0.058 seconds)
> {noformat}
> This is the difference between using Apache Phoenix's avatica client and the
> normal client and sqlline 1.1.9. With {{!outputformat table}} above, we can
> see the difference in these two clients, while {{!outputformat xmlattr}}
> shows the complete (and expected) values.
> It seems like some column metadata is just not being properly sent by PQS (at
> least that's my hunch). The data is present in the results, just not rendered
> properly. I'll have to look into what sqlline pulls for the column width and
> figure out if PQS is sending that properly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1428) Inefficient execution plan of SELECT and LIMIT for Druid
[
https://issues.apache.org/jira/browse/CALCITE-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1428:
-
Fix Version/s: 1.11.0
> Inefficient execution plan of SELECT and LIMIT for Druid
>
>
> Key: CALCITE-1428
> URL: https://issues.apache.org/jira/browse/CALCITE-1428
> Project: Calcite
> Issue Type: Bug
> Components: core, druid
>Reporter: Jiarong Wei
>Assignee: Julian Hyde
> Fix For: 1.11.0
>
>
> For SQLs like:
> 1. {{SELECT * FROM LIMIT }}
> 2. {{SELECT FROM LIMIT
> }}
> {{DruidSortRule}} in Druid adapter does take effect and {{LIMIT}} is pushed
> into {{DruidQuery}}. However the corresponding execution plan isn't chosen as
> the best one. Thus Calcite will retrieve all data from Druid and purge all
> unnecessary columns.
> These are three SQLs and their corresponding execution plans below for
> dataset {{wikiticker}} in Druid quickstart:
> 1. {{SELECT "cityName" FROM "wikiticker" LIMIT 5}}
> {code}
> rel#27:EnumerableInterpreter.ENUMERABLE.[](input=rel#26:Subset#2.BINDABLE.[])
> rel#85:DruidQuery.BINDABLE.[](table=[default,
> wikiticker],intervals=[1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z],projects=[$3],fetch=5)
> {code}
> 2. {{SELECT * FROM "wikiticker" LIMIT 5}}
> {code}
> rel#52:EnumerableLimit.ENUMERABLE.[](input=rel#36:Subset#0.ENUMERABLE.[],fetch=5)
> rel#79:EnumerableInterpreter.ENUMERABLE.[](input=rel#4:Subset#0.BINDABLE.[])
> rel#1:DruidQuery.BINDABLE.[](table=[default,
> wikiticker],intervals=[1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z])
> {code}
> 3. {{SELECT "__time", "added", "channel", "cityName", "comment",
> "commentLength", "count", "countryIsoCode", "countryName", "deleted",
> "delta", "deltaBucket", "diffUrl", "flags", "isAnonymous", "isMinor",
> "isNew", "isRobot", "isUnpatrolled", "metroCode", "namespace", "page",
> "regionIsoCode", "regionName", "user", "user_unique" FROM "wikiticker" LIMIT
> 5}}
> {code}
> rel#42:EnumerableLimit.ENUMERABLE.[](input=rel#41:Subset#1.ENUMERABLE.[],fetch=5)
> rel#113:EnumerableInterpreter.ENUMERABLE.[](input=rel#34:Subset#1.BINDABLE.[])
> rel#52:BindableProject.BINDABLE.[](input=rel#4:Subset#0.BINDABLE.[],__time=$0,added=$1,channel=$2,cityName=$3,comment=$4,commentLength=$5,count=$6,countryIsoCode=$7,countryName=$8,deleted=$9,delta=$10,deltaBucket=$11,diffUrl=$12,flags=$13,isAnonymous=$14,isMinor=$15,isNew=$16,isRobot=$17,isUnpatrolled=$18,metroCode=$19,namespace=$20,page=$21,regionIsoCode=$22,regionName=$23,user=USER,user_unique=$25)
> rel#1:DruidQuery.BINDABLE.[](table=[default,
> wikiticker],intervals=[1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z])
> {code}
> Notice that 2 and 3 should have {{LIMIT}} pushed to {{DruidQuery}} like 1
> (and should not have {{EnumerableLimit}})
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1383) Allow extensions to existing Calcite parser rules
[
https://issues.apache.org/jira/browse/CALCITE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1383:
-
Fix Version/s: 1.11.0
> Allow extensions to existing Calcite parser rules
> -
>
> Key: CALCITE-1383
> URL: https://issues.apache.org/jira/browse/CALCITE-1383
> Project: Calcite
> Issue Type: Improvement
>Reporter: James Taylor
>Assignee: Julian Hyde
> Fix For: 1.11.0
>
>
> In Phoenix, we'd like to add some Phoenix-specific commands in support of our
> UDF implementation. For example, we'd like to add commands like to manage the
> jars containing the implementation of the UDFs:
> - {{ALTER SYSTEM ADD JAR ...}}
> - {{ALTER SYSTEM LIST JARS}}
> Without copy/pasting the entire parser grammar for the command (see comment
> here[1]), it seems there's no easy way to do it. Perhaps we're missing
> something and there's already an easy way?
> [1]
> https://issues.apache.org/jira/browse/PHOENIX-3242?focusedCommentId=15512529=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15512529
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1441) DOUBLE is returned as BigDecimal with JSON serialization
[ https://issues.apache.org/jira/browse/CALCITE-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1441: - Fix Version/s: 1.11.0 > DOUBLE is returned as BigDecimal with JSON serialization > > > Key: CALCITE-1441 > URL: https://issues.apache.org/jira/browse/CALCITE-1441 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 1.11.0 > > > Noticed in my testing for ARRAY support: > Serializing a DOUBLE results in Jackson using BigDecimal. This type is > directly returned to the user instead of being correctly returned as a Double > per the JDBC 4.1 specification, Table B-1: "JDBC Types Mapped to Java Types" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1457) Parser keyword conflict with UDF(insert, left, etc.)
[ https://issues.apache.org/jira/browse/CALCITE-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1457: - Fix Version/s: 1.11.0 > Parser keyword conflict with UDF(insert, left, etc.) > > > Key: CALCITE-1457 > URL: https://issues.apache.org/jira/browse/CALCITE-1457 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Baofeng Zhang >Assignee: Julian Hyde >Priority: Trivial > Fix For: 1.11.0 > > > UPDATE: close me :) > Hi guys, > I try to implement MySQL function like INSERT(str, pos, len, newts), > LEFT(str, len), but these functions have the same keyword defined in > Parser.jj, which leads to mistake during sql parser procedure. > Can anyone help me to get around this? Thx! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1460) Make Planner object Autocloseable
[ https://issues.apache.org/jira/browse/CALCITE-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1460: - Fix Version/s: 1.11.0 > Make Planner object Autocloseable > - > > Key: CALCITE-1460 > URL: https://issues.apache.org/jira/browse/CALCITE-1460 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Chinmay Kolhatkar >Assignee: Julian Hyde > Fix For: 1.11.0 > > > Planner object currently cannot be used with try-with-resources.. Planner > interface needs to be AutoCloseable for that. -- 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=15603114#comment-15603114
]
Julian Hyde commented on CALCITE-1353:
--
[~francischuang], Would you (or anyone else) like to develop a PR for this?
> 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.10.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-1453) Support ANY type with binary compare / arithmetic operators
[
https://issues.apache.org/jira/browse/CALCITE-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602828#comment-15602828
]
Julian Hyde commented on CALCITE-1453:
--
The new `SqlFunctions` methods support a lot of permutations, so I think we
need corresponding tests added to `SqlFunctionsTest`.
I am worried that bugs in the code generator (CALCITE-1467 is a recent example)
will end up calling a function with Object arguments and giving poor runtime
performance. How can we prevent that? Could we change the name of these
fallback functions, say {{multiply(Object, Object)}} becomes
{{multiplyAny(Object, Object)}}?
> Support ANY type with binary compare / arithmetic operators
> ---
>
> Key: CALCITE-1453
> URL: https://issues.apache.org/jira/browse/CALCITE-1453
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jungtaek Lim
>Assignee: Jungtaek Lim
>
> Currently Calcite doesn't support applying binary compare / arithmetic
> operators with ANY type. One of example is
> CollectionTypeTest.testAccessNestedMapWithAnyTypeWithoutCast(). Without
> explicit casting, it can't find the matching backup method, and complaining
> there's no SqlFunctions.eq(Object, int).
> There seems to several ways to resolve this, but at least we don't want to
> make operator backup method for every combination of types. Needs to avoid
> this approach.
> When we're addressing this by having backup method, since we don't know the
> runtime type for ANY type, even if we succeed to call backup method with
> (Object, Object) parameters, two types can be different. This is OK for other
> types, but not Number types. This should be well cared, too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1467) SqlFunctions power
[ https://issues.apache.org/jira/browse/CALCITE-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602402#comment-15602402 ] Julian Hyde commented on CALCITE-1467: -- I thought that the existing methods were sufficient; the code generator generates appropriate conversions. Can you provide a test case that fails and its error stack? > SqlFunctions power > -- > > Key: CALCITE-1467 > URL: https://issues.apache.org/jira/browse/CALCITE-1467 > Project: Calcite > Issue Type: Bug >Reporter: Anton Solovev >Assignee: Julian Hyde > > there are only 3 power methods: > double power(double b0, double b1) > double power(long b0, long b1) > double power(long b0, BigDecimal b1) > in org.apache.calcite.runtime.SqlFunctions > but methods are unsuitable with double power(double b0, BigDecimal b1) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1467) SqlFunctions power
[ https://issues.apache.org/jira/browse/CALCITE-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Solovev updated CALCITE-1467: --- Description: there are only 3 power methods: double power(double b0, double b1) double power(long b0, long b1) double power(long b0, BigDecimal b1) in org.apache.calcite.runtime.SqlFunctions but methods are unsuitable with double power(double b0, BigDecimal b1) was: there are only 3 power methods: double power(double b0, double b1) double power(long b0, long b1) double power(long b0, BigDecimal b1) in org.apache.calcite.runtime.SqlFunctions but methods are unsuitable with (float, float), (float, BigDecimal) > SqlFunctions power > -- > > Key: CALCITE-1467 > URL: https://issues.apache.org/jira/browse/CALCITE-1467 > Project: Calcite > Issue Type: Bug >Reporter: Anton Solovev >Assignee: Julian Hyde > > there are only 3 power methods: > double power(double b0, double b1) > double power(long b0, long b1) > double power(long b0, BigDecimal b1) > in org.apache.calcite.runtime.SqlFunctions > but methods are unsuitable with double power(double b0, BigDecimal b1) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1467) SqlFunctions power
Anton Solovev created CALCITE-1467: -- Summary: SqlFunctions power Key: CALCITE-1467 URL: https://issues.apache.org/jira/browse/CALCITE-1467 Project: Calcite Issue Type: Bug Reporter: Anton Solovev Assignee: Julian Hyde there are only 3 power methods: double power(double b0, double b1) double power(long b0, long b1) double power(long b0, BigDecimal b1) in org.apache.calcite.runtime.SqlFunctions but methods are unsuitable with (float, float), (float, BigDecimal) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1461) Hard coded class name in JaninoRelMetadataProvider breaks shading
[
https://issues.apache.org/jira/browse/CALCITE-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601168#comment-15601168
]
Jark Wu commented on CALCITE-1461:
--
Here is the PR link: https://github.com/apache/calcite/pull/318
> Hard coded class name in JaninoRelMetadataProvider breaks shading
> -
>
> Key: CALCITE-1461
> URL: https://issues.apache.org/jira/browse/CALCITE-1461
> Project: Calcite
> Issue Type: Bug
>Reporter: Jark Wu
>Assignee: Julian Hyde
>
> In {{JaninoRelMetadataProvider.load3}}, the generated class string contains
> some hard coded Calcite's classes, such as
> {{org.apache.calcite.rel.metadata.MetadataDef}}. After shading Calcite, the
> MetadataDef can not be found in the shaded classes. And a compile error will
> be thrown.
> So it's better to use {{MetadataDef.class.getName()}} to replace the hard
> code string.
> I'm appreciate to make a PR if you want.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1466) Support for UNSIGNED types of int,long,float etc. in type system
Rajeshbabu Chintaguntla created CALCITE-1466: Summary: Support for UNSIGNED types of int,long,float etc. in type system Key: CALCITE-1466 URL: https://issues.apache.org/jira/browse/CALCITE-1466 Project: Calcite Issue Type: Bug Components: avatica Reporter: Rajeshbabu Chintaguntla There are some data bases like MySQL supporting unsigned data types. Apache Phoenix also supports them. Would be great to add them to calcite as well. http://dev.mysql.com/doc/refman/5.7/en/integer-types.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1466) Support for UNSIGNED types of int,long,float etc. in type system
[ https://issues.apache.org/jira/browse/CALCITE-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601119#comment-15601119 ] Rajeshbabu Chintaguntla commented on CALCITE-1466: -- FYI [~julianhyde] [~maryannxue] [~jamestaylor]. > Support for UNSIGNED types of int,long,float etc. in type system > > > Key: CALCITE-1466 > URL: https://issues.apache.org/jira/browse/CALCITE-1466 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Rajeshbabu Chintaguntla > > There are some data bases like MySQL supporting unsigned data types. Apache > Phoenix also supports them. Would be great to add them to calcite as well. > http://dev.mysql.com/doc/refman/5.7/en/integer-types.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
