[jira] [Commented] (CALCITE-3009) DiffRepository should fail if XML resource file contains duplicate test names
[
https://issues.apache.org/jira/browse/CALCITE-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822601#comment-16822601
]
Julian Hyde commented on CALCITE-3009:
--
Reviewing now. Looks good, and I should be able to commit soon.
> DiffRepository should fail if XML resource file contains duplicate test names
> -
>
> Key: CALCITE-3009
> URL: https://issues.apache.org/jira/browse/CALCITE-3009
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.19.0
>Reporter: Chunwei Lei
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> There are duplicate keys for {{testProjectCorrelateTranspose}} in
> RelOptRulesTest.xml[1][2]. We should add a test to make it fail when having
> duplicate keys in a {{.xml}} file.
>
> [1]
> [https://github.com/apache/calcite/blob/master/core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml#L9226]
> [2]
> [https://github.com/apache/calcite/blob/master/core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml#L9253]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-3009) DiffRepository should fail if XML resource file contains duplicate test names
[
https://issues.apache.org/jira/browse/CALCITE-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-3009:
-
Summary: DiffRepository should fail if XML resource file contains duplicate
test names (was: Duplicate key is not detected in xml answer file)
> DiffRepository should fail if XML resource file contains duplicate test names
> -
>
> Key: CALCITE-3009
> URL: https://issues.apache.org/jira/browse/CALCITE-3009
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.19.0
>Reporter: Chunwei Lei
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> There are duplicate keys for {{testProjectCorrelateTranspose}} in
> RelOptRulesTest.xml[1][2]. We should add a test to make it fail when having
> duplicate keys in a {{.xml}} file.
>
> [1]
> [https://github.com/apache/calcite/blob/master/core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml#L9226]
> [2]
> [https://github.com/apache/calcite/blob/master/core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml#L9253]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2983) Add Avatica compatibility page for TLS and IBM Java
[ https://issues.apache.org/jira/browse/CALCITE-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822593#comment-16822593 ] Francis Chuang commented on CALCITE-2983: - [~krisden] Are you still planning to get this into Avatica 1.14.0? > Add Avatica compatibility page for TLS and IBM Java > --- > > Key: CALCITE-2983 > URL: https://issues.apache.org/jira/browse/CALCITE-2983 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Kevin Risden >Priority: Major > Fix For: avatica-1.14.0 > > > With the Jetty upgrade in CALCITE-2972, there are some compatibility issues > between TLS support and IBM Java. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-3009) Duplicate key is not detected in xml answer file
[
https://issues.apache.org/jira/browse/CALCITE-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Haisheng Yuan updated CALCITE-3009:
---
Summary: Duplicate key is not detected in xml answer file (was: Duplicate
test cases in the .xml file)
> Duplicate key is not detected in xml answer file
>
>
> Key: CALCITE-3009
> URL: https://issues.apache.org/jira/browse/CALCITE-3009
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.19.0
>Reporter: Chunwei Lei
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> There are duplicate keys for {{testProjectCorrelateTranspose}} in
> RelOptRulesTest.xml[1][2]. We should add a test to make it fail when having
> duplicate keys in a {{.xml}} file.
>
> [1]
> [https://github.com/apache/calcite/blob/master/core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml#L9226]
> [2]
> [https://github.com/apache/calcite/blob/master/core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml#L9253]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2712) Add rule to remove null-generating side of a Join
[
https://issues.apache.org/jira/browse/CALCITE-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822511#comment-16822511
]
Julian Hyde commented on CALCITE-2712:
--
Thanks for the refactorings, and for adding ProjectJoinJoinRemoveRule. I think
there are still a couple of improvements to make your utility methods more
general purpose:
* Rather than {{shift}}, could you use {{AggregateCall.transform}}? It handles
all of the obscure stuff like filter and collation.
* Could you make the {{canRemoveJoin}} more general purpose. Currently it is
*almost* general purpose - its name says join but it is really just working in
terms of field offset. Make them generate an {{ImmutableBitSet}} of fields
used. Then the caller can decide whether those fields correspond to the left or
right join inputs. See InputFinder and how is used by various utility methods.
> Add rule to remove null-generating side of a Join
> -
>
> Key: CALCITE-2712
> URL: https://issues.apache.org/jira/browse/CALCITE-2712
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Add a rule to remove the null-generating side of a Join. Here is an example
> where we eliminate the "many" side of a "one-to-many" join:
> {code:sql}
> # Example 1: one-to-many
> SELECT c.id, COUNT(DISTINCT o.productId)
> FROM Customers AS c
> LEFT JOIN SupportCalls AS s ON c.id = s.customerId
> LEFT JOIN Orders AS o ON c.id = o.customerId{code}
> We can remove {{SupportCalls}} and the join to it, so the query becomes
> {code:sql}
> SELECT c.id, COUNT(DISTINCT o.productId)
> FROM Customers AS c
> LEFT JOIN Orders AS o ON c.id = o.customerId{code}
> Necessary conditions are:
> # no columns from {{SupportCalls}} are used
> # the join is LEFT, so customers will not be eliminated if they have no
> support calls,
> # there is an Aggregate on top, so we don't care if there are >1 support call
> per customer.
> A simpler example of one-to-many:
> {code:sql}
> # Example 2: simpler one-to-many
> SELECT DISTINCT c.id
> FROM Customers AS c
> LEFT JOIN SupportCalls AS s ON c.id = s.customerId{code}
> An example of many-to-one, where we eliminate the "one" side ({{Orders}}):
> {code:sql}
> # Example 3: many-to-one
> SELECT c.id, p.color
> FROM LineItems AS i
> LEFT JOIN Orders AS o ON o.id = i.orderId
> LEFT JOIN Products AS p ON p.id = i.orderId{code}
> so that the query becomes
> {code:sql}
> SELECT c.id, p.color
> FROM LineItems AS i
> LEFT JOIN Products AS p ON p.id = i.orderId{code}
> Here, necessary side-conditions are:
> # no columns from {{Orders}} are used;
> # unique key on {{Orders.id}}.
> We do not require aggregation, because the primary key on {{Orders.id}}
> ensures that {{Orders}} contributes at most one row.
> We can deal with similar cases like
> {code:sql}
> # Example 4: many-to-one, column aliasing required
> SELECT c.id, p.color
> FROM LineItems AS i
> LEFT JOIN Orders AS o ON o.id = i.orderId
> LEFT JOIN Products AS p ON p.id = o.id{code}
> if we use aliasing ({{o.id}} = {{i.orderId}}) and a foreign key that ensures
> the existence of an record in {{Orders}}.
> For examples 1 and 2 (one-to-many), we would need to match {{Aggregate}} on
> {{Join}}, therefore make a variant of {{AggregateJoinTransposeRule}}.
> For examples 3 and 4 (many-to-one or one-to-one)), we would match {{Project}}
> on {{Join}}, therefore make a variant of {{ProjectJoinTransposeRule}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-2986) Wrong results with =ANY subquery
[
https://issues.apache.org/jira/browse/CALCITE-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Haisheng Yuan resolved CALCITE-2986.
Resolution: Fixed
Fix Version/s: 1.20.0
Fixed in
https://github.com/apache/calcite/commit/cd9697398959bf518b255d1c59e7686c45f39646,
thanks for the PR, [~vgarg]!
> Wrong results with =ANY subquery
>
>
> Key: CALCITE-2986
> URL: https://issues.apache.org/jira/browse/CALCITE-2986
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Vineet Garg
>Assignee: Vineet Garg
>Priority: Major
> Labels: pull-request-available, sub-query
> Fix For: 1.20.0
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> ANY/SOME subqueries are rewritten using MAX/MIN and cross-join. This is wrong
> transformation for {{=ANY}} and {{<>ANY}} (and therefore {{=ALL}} and
> {{<>ALL}}).
> Query
> {code:sql}
> select * from "scott".emp where empno = any (select empno from "scott".emp);
> {code}
> Expected output for above query is all rows from {{scott.emp}} but actual is
> only one row
> Test case: e.g.
> https://github.com/apache/calcite/compare/master...vineetgarg02:CALCITE-2986
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2453) Enhance the SQL parser in order to optionally support semicolon at the end of the sql statements
[
https://issues.apache.org/jira/browse/CALCITE-2453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822502#comment-16822502
]
Chunwei Lei commented on CALCITE-2453:
--
{quote}The first statement is parsed successfully and the second one failed.
Should we keep result of the first statement? Or should we consider it as a
failure?
{quote}
Sorry, I change my idea. I think it is better to consider it as a failure when
meeting an error statement which seems more reasonable.
Besides, I find PR#783 is not as good as expected since it treats some negative
test cases as success wrongly. For instance, the following sql
{code:java}
select * from emp where name like 'toto'; delete from emp; delete from emp
select * from dept
{code}
will be parsed successfully. As a result, I opened a new pull request:
[https://github.com/apache/calcite/pull/1177|https://github.com/apache/calcite/pull/1177/].
The major changes in the new PR are as follows:
* Correct the wrong definition in the .jj file
* Add some negative test cases
* Resolve conflicts
> Enhance the SQL parser in order to optionally support semicolon at the end of
> the sql statements
>
>
> Key: CALCITE-2453
> URL: https://issues.apache.org/jira/browse/CALCITE-2453
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: next
>Reporter: charbel yazbeck
>Assignee: Chunwei Lei
>Priority: Trivial
> Labels: pull-request-available
> Attachments:
> 0001-CALCITE-2453-Allowing-SQL-statements-to-optionally-e.patch
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Consists of adding [] in Parser.jj
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-2962) RelStructuredTypeFlattener generates wrong types for nested column when flattenProjection
[ https://issues.apache.org/jira/browse/CALCITE-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis resolved CALCITE-2962. -- Resolution: Fixed Fix Version/s: 1.20.0 Fixed in [a51a187c2216351905d0da552dd59479ba5b6bd6|https://github.com/apache/calcite/commit/a51a187c2216351905d0da552dd59479ba5b6bd6]! Thanks again for the PR [~my7ym] :) > RelStructuredTypeFlattener generates wrong types for nested column when > flattenProjection > - > > Key: CALCITE-2962 > URL: https://issues.apache.org/jira/browse/CALCITE-2962 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.19.0 >Reporter: Will Yu >Assignee: Will Yu >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > RelStructuredTypeFlattener generates wrong types for nested column when > flattenProjection. This problem is similar to CALCITE-2900 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3000) Improve SqlUserDefinedFunction and SqlUserDefinedTableFunction to support overload method call
[
https://issues.apache.org/jira/browse/CALCITE-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822403#comment-16822403
]
pengzhiwei edited comment on CALCITE-3000 at 4/20/19 9:52 AM:
--
Hi [~julianhyde], the description of the issue has been updated and a PR has
pulled.
Here is the mainly change list in this PR:
# Add {{SqlUtil#findBestMatchMethod}} to support find best matched method in
the function class.
# Support dynamic type inference according to the calling argument types based
on (1).({{SqlFunction#getReturnTypeInferenceForClass}}、
{{SqlFunction#getOperandTypeInferenceForClass }} and
{{SqlFunction#getOperandTypeCheckerForClass}})
# Add {{argTypes}} and {{typeFactory}} parameters to
{{ImplementableFunction#getImplementor}} to create {{CallImplementor}}
according to the argument types.
# Add {{argTypes}} and {{typeFactory}} parameters to
{{TableFunction#getRowType}} to infer return type according to the argument
types.
# Add {{JavaScalarFunction}} and {{JavaTableFunction}} to represent the
class-level function schema mapping a java class.
was (Author: pzw2018):
Hi [~julianhyde], the description of the issue has been updated and a PR has
pulled.
Here is the mainly change list in this PR:
# Add {{SqlUtil#findBestMatchMethod}} to support find best matched method in
the function class.
# Support dynamic type inference according to the calling argument types based
on (1).({{SqlFunction#getReturnTypeInferenceForClass}}、
{{SqlFunction#getOperandTypeInferenceForClass }} and
{{SqlFunction#getOperandTypeCheckerForClass}})
# Add {{argTypes}} and {{typeFactory}} parameters to
{{ImplementableFunction#getImplementor}} to create {{CallImplementor}}
according to the argument types.
# Add {{argTypes}} and {{typeFactory}} parameters to
{{TableFunction#getRowType}} to infer return type according to the argument
types.
# Add {{JavaScalarFunction}} and {{JavaTableFunction}} to represent the
function schema mapping a java class.
> Improve SqlUserDefinedFunction and SqlUserDefinedTableFunction to support
> overload method call
> --
>
> Key: CALCITE-3000
> URL: https://issues.apache.org/jira/browse/CALCITE-3000
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Here are User-defined scalar function class and table function class:
>
> {code:java}
> @UDFDescription(name = "MY_UDF", category =
> SqlFunctionCategory.USER_DEFINED_FUNCTION)
> public static class MyUdfFunction {
> public static String eval(String a) {
> ...
> }
> public static String eval(String a, String b) {
>
> }
> public static String eval(String a, int c) {
>
> }
> }
> {code}
> {code:java}
> @UDFDescription(name = "MY_UDTF", category =
> SqlFunctionCategory.USER_DEFINED_TABLE_FUNCTION)
> public static class MyUdtfFunction {
> public static MyScannableTable eval(String a) {
> ...
> }
> public static MyScannableTable eval(long a) {
> ...
> }
> public static MyScannableTable eval(int a) {
> ...
> }
> }
> {code}
> This issue wants to improve the SqlUserDefinedFunction and
> SqlUserDefinedTableFunction to support the overload functions in both
> User-defined scalar function class and table function class.
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3000) Improve SqlUserDefinedFunction and SqlUserDefinedTableFunction to support overload method call
[
https://issues.apache.org/jira/browse/CALCITE-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822403#comment-16822403
]
pengzhiwei commented on CALCITE-3000:
-
Hi [~julianhyde], the description of the issue has been updated and a PR has
pulled.
Here is the mainly change list in this PR:
# Add {{SqlUtil#findBestMatchMethod}} to support find best matched method in
the function class.
# Support dynamic type inference according to the calling argument types based
on (1).({{SqlFunction#getReturnTypeInferenceForClass}}、
{{SqlFunction#getOperandTypeInferenceForClass }} and
{{SqlFunction#getOperandTypeCheckerForClass}})
# Add {{argTypes}} and {{typeFactory}} parameters to
{{ImplementableFunction#getImplementor}} to create {{CallImplementor}}
according to the argument types.
# Add {{argTypes}} and {{typeFactory}} parameters to
{{TableFunction#getRowType}} to infer return type according to the argument
types.
# Add {{JavaScalarFunction}} and {{JavaTableFunction}} to represent the
function schema mapping a java class.
> Improve SqlUserDefinedFunction and SqlUserDefinedTableFunction to support
> overload method call
> --
>
> Key: CALCITE-3000
> URL: https://issues.apache.org/jira/browse/CALCITE-3000
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Here are User-defined scalar function class and table function class:
>
> {code:java}
> @UDFDescription(name = "MY_UDF", category =
> SqlFunctionCategory.USER_DEFINED_FUNCTION)
> public static class MyUdfFunction {
> public static String eval(String a) {
> ...
> }
> public static String eval(String a, String b) {
>
> }
> public static String eval(String a, int c) {
>
> }
> }
> {code}
> {code:java}
> @UDFDescription(name = "MY_UDTF", category =
> SqlFunctionCategory.USER_DEFINED_TABLE_FUNCTION)
> public static class MyUdtfFunction {
> public static MyScannableTable eval(String a) {
> ...
> }
> public static MyScannableTable eval(long a) {
> ...
> }
> public static MyScannableTable eval(int a) {
> ...
> }
> }
> {code}
> This issue wants to improve the SqlUserDefinedFunction and
> SqlUserDefinedTableFunction to support the overload functions in both
> User-defined scalar function class and table function class.
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (CALCITE-3000) Improve SqlUserDefinedFunction and SqlUserDefinedTableFunction to support overload method call
[
https://issues.apache.org/jira/browse/CALCITE-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-3000:
Comment: was deleted
(was: Hi [~julianhyde], I mean overload function.Thanks for your correction.
Here is the example :
{code:java}
@Function(name = "my_udf")
public class MyUdf {
public static String eval(String arg0,String arg1) {...}
public static String eval(long arg0, long arg1){...}
public static String eval(int arg0, int arg1) {...}
}{code}
_MyUdf_ is a user defined scalar function named "my_udf" with multiple
overload method. Currently the ModelHandler would register multiple
ScalarFunctions to the schema for each method.
I would like to mapping one SqlUserDefinedFunction to "my_udf" no mater how
many overload functions it has just like the BuildIn operator.
To implement this, I will extend the Types#lookupMethod:
{code:java}
public static Method lookupMethod(Class clazz,String name, Class... inputTypes)
{
// Find the best match method from the overload functions for the input types.
}{code}
In the SqlReturnTypeInference for SqlUserDefinedFunction, I can use the
Types#lookupMethod to infer the return type :
{code:java}
SqlReturnTypeInference returnTypeInference =
opBinding -> {
..
List paramTypes = convertToJavaTypes(
opBinding.collectOperandTypes(), opBinding.getTypeFactory());
Method method = Types.lookupMethod(udfClazz, "eval", paramTypes);
return typeFactory.createType(method.getReturnType());
}{code}
The similar thing can apply to SqlOperandTypeInference and
SqlOperandTypeChecker.
So we can implement a dynamic type inference for the overload functions in
scalar function. And there is only one SqlUserDefinedFunction mapping to the
sql function.
We can also do the same thing for SqlUserDefinedTableFunction for the "my_udtf"
as followed:
{code:java}
@Function(name = "my_udtf")
public class MyUdtf {
public static ScannableTable eval(String arg0,String arg1) {...}
public static ScannableTable eval(long arg0, long arg1) {...}
public static ScannableTable eval(int arg0, int arg1) {...}
}
{code}
We mapping one SqlUserDefinedTableFunction to the "my_udtf" table function and
support all the overload methods call.
)
> Improve SqlUserDefinedFunction and SqlUserDefinedTableFunction to support
> overload method call
> --
>
> Key: CALCITE-3000
> URL: https://issues.apache.org/jira/browse/CALCITE-3000
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Here are User-defined scalar function class and table function class:
>
> {code:java}
> @UDFDescription(name = "MY_UDF", category =
> SqlFunctionCategory.USER_DEFINED_FUNCTION)
> public static class MyUdfFunction {
> public static String eval(String a) {
> ...
> }
> public static String eval(String a, String b) {
>
> }
> public static String eval(String a, int c) {
>
> }
> }
> {code}
> {code:java}
> @UDFDescription(name = "MY_UDTF", category =
> SqlFunctionCategory.USER_DEFINED_TABLE_FUNCTION)
> public static class MyUdtfFunction {
> public static MyScannableTable eval(String a) {
> ...
> }
> public static MyScannableTable eval(long a) {
> ...
> }
> public static MyScannableTable eval(int a) {
> ...
> }
> }
> {code}
> This issue wants to improve the SqlUserDefinedFunction and
> SqlUserDefinedTableFunction to support the overload functions in both
> User-defined scalar function class and table function class.
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-3000) Improve SqlUserDefinedFunction and SqlUserDefinedTableFunction to support overload method call
[
https://issues.apache.org/jira/browse/CALCITE-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-3000:
Description:
Here are User-defined scalar function class and table function class:
{code:java}
@UDFDescription(name = "MY_UDF", category =
SqlFunctionCategory.USER_DEFINED_FUNCTION)
public static class MyUdfFunction {
public static String eval(String a) {
...
}
public static String eval(String a, String b) {
}
public static String eval(String a, int c) {
}
}
{code}
{code:java}
@UDFDescription(name = "MY_UDTF", category =
SqlFunctionCategory.USER_DEFINED_TABLE_FUNCTION)
public static class MyUdtfFunction {
public static MyScannableTable eval(String a) {
...
}
public static MyScannableTable eval(long a) {
...
}
public static MyScannableTable eval(int a) {
...
}
}
{code}
This issue wants to improve the SqlUserDefinedFunction and
SqlUserDefinedTableFunction to support the overload functions in both
User-defined scalar function class and table function class.
was:
Here are User-defined scalar function class and table function class:
{code:java}
@UDFDescription(name = "MY_UDF", category =
SqlFunctionCategory.USER_DEFINED_FUNCTION)
public static class MyUdfFunction {
public static String eval(String a) {
...
}
public static String eval(String a, String b) {
}
public static String eval(String a, int c) {
}
}
{code}
{code:java}
@UDFDescription(name = "MY_UDTF", category =
SqlFunctionCategory.USER_DEFINED_TABLE_FUNCTION)
public static class MyUdtfFunction {
public static MyScannableTable eval(String a) {
...
}
public static MyScannableTable eval(long a) {
...
}
public static MyScannableTable eval(int a) {
...
}
}
{code}
This issue wants to improve SqlUserDefinedFunction and
> Improve SqlUserDefinedFunction and SqlUserDefinedTableFunction to support
> overload method call
> --
>
> Key: CALCITE-3000
> URL: https://issues.apache.org/jira/browse/CALCITE-3000
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Here are User-defined scalar function class and table function class:
>
> {code:java}
> @UDFDescription(name = "MY_UDF", category =
> SqlFunctionCategory.USER_DEFINED_FUNCTION)
> public static class MyUdfFunction {
> public static String eval(String a) {
> ...
> }
> public static String eval(String a, String b) {
>
> }
> public static String eval(String a, int c) {
>
> }
> }
> {code}
> {code:java}
> @UDFDescription(name = "MY_UDTF", category =
> SqlFunctionCategory.USER_DEFINED_TABLE_FUNCTION)
> public static class MyUdtfFunction {
> public static MyScannableTable eval(String a) {
> ...
> }
> public static MyScannableTable eval(long a) {
> ...
> }
> public static MyScannableTable eval(int a) {
> ...
> }
> }
> {code}
> This issue wants to improve the SqlUserDefinedFunction and
> SqlUserDefinedTableFunction to support the overload functions in both
> User-defined scalar function class and table function class.
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-3000) Improve SqlUserDefinedFunction and SqlUserDefinedTableFunction to support overload method call
[
https://issues.apache.org/jira/browse/CALCITE-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-3000:
Description:
Here are User-defined scalar function class and table function class:
{code:java}
@UDFDescription(name = "MY_UDF", category =
SqlFunctionCategory.USER_DEFINED_FUNCTION)
public static class MyUdfFunction {
public static String eval(String a) {
...
}
public static String eval(String a, String b) {
}
public static String eval(String a, int c) {
}
}
{code}
{code:java}
@UDFDescription(name = "MY_UDTF", category =
SqlFunctionCategory.USER_DEFINED_TABLE_FUNCTION)
public static class MyUdtfFunction {
public static MyScannableTable eval(String a) {
...
}
public static MyScannableTable eval(long a) {
...
}
public static MyScannableTable eval(int a) {
...
}
}
{code}
This issue wants to improve SqlUserDefinedFunction and
was:
Here are User-defined scalar function class and table function class:
{code:java}
@UDFDescription(name = "MY_UDF", category =
SqlFunctionCategory.USER_DEFINED_FUNCTION)
public static class MyUdfFunction {
public static String eval(String a) {
...
}
public static String eval(String a, String b) {
}
public static String eval(String a, int c) {
}
}
{code}
{code:java}
@UDFDescription(name = "MY_UDTF", category =
SqlFunctionCategory.USER_DEFINED_TABLE_FUNCTION)
public static class MyUdtfFunction {
public static MyScannableTable eval(String a) {
...
}
public static MyScannableTable eval(long a) {
...
}
public static MyScannableTable eval(int a) {
...
}
}
{code}
This issue wants to improve
> Improve SqlUserDefinedFunction and SqlUserDefinedTableFunction to support
> overload method call
> --
>
> Key: CALCITE-3000
> URL: https://issues.apache.org/jira/browse/CALCITE-3000
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Here are User-defined scalar function class and table function class:
>
> {code:java}
> @UDFDescription(name = "MY_UDF", category =
> SqlFunctionCategory.USER_DEFINED_FUNCTION)
> public static class MyUdfFunction {
> public static String eval(String a) {
> ...
> }
> public static String eval(String a, String b) {
>
> }
> public static String eval(String a, int c) {
>
> }
> }
> {code}
> {code:java}
> @UDFDescription(name = "MY_UDTF", category =
> SqlFunctionCategory.USER_DEFINED_TABLE_FUNCTION)
> public static class MyUdtfFunction {
> public static MyScannableTable eval(String a) {
> ...
> }
> public static MyScannableTable eval(long a) {
> ...
> }
> public static MyScannableTable eval(int a) {
> ...
> }
> }
> {code}
> This issue wants to improve SqlUserDefinedFunction and
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-3000) Improve SqlUserDefinedFunction and SqlUserDefinedTableFunction to support overload method call
[
https://issues.apache.org/jira/browse/CALCITE-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-3000:
Description:
Here are User-defined scalar function class and table function class:
{code:java}
@UDFDescription(name = "MY_UDF", category =
SqlFunctionCategory.USER_DEFINED_FUNCTION)
public static class MyUdfFunction {
public static String eval(String a) {
...
}
public static String eval(String a, String b) {
}
public static String eval(String a, int c) {
}
}
{code}
{code:java}
@UDFDescription(name = "MY_UDTF", category =
SqlFunctionCategory.USER_DEFINED_TABLE_FUNCTION)
public static class MyUdtfFunction {
public static MyScannableTable eval(String a) {
...
}
public static MyScannableTable eval(long a) {
...
}
public static MyScannableTable eval(int a) {
...
}
}
{code}
This issue wants to improve
was:
Currently the ModelHandler adds one Function to the schema for one java
method. For the scalar function,ModelHandler resolves all the method in the
class and translate each of them to ScalarFunction to support overload method
call. But for TableFunction, this has not been support yet.
Maybe we can support it as the scalar function does. However in that way,
one sql function may match multiple Functions in the schema.I think this is not
a good way. It is better to have only one Function in the schema for one sql
function just like the BuildIn operator.
I'd like to support a new operand type check strategy for
SqlUserDefinedFunction and SqlUserDefinedTableFunction which can infer the
operand type and return type according to the input parameter types.
I will extend the Types#lookupMethod to support finding the best method in
all of the override methods in a class. And the
SqlReturnTypeInference、SqlOperandTypeInference and
SqlOperandTypeChecker can use this to do the type inference according to the
input types. I think it is a dynamically way compared with the original way.
Any suggestion is welcomed,thanks!
> Improve SqlUserDefinedFunction and SqlUserDefinedTableFunction to support
> overload method call
> --
>
> Key: CALCITE-3000
> URL: https://issues.apache.org/jira/browse/CALCITE-3000
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Here are User-defined scalar function class and table function class:
>
> {code:java}
> @UDFDescription(name = "MY_UDF", category =
> SqlFunctionCategory.USER_DEFINED_FUNCTION)
> public static class MyUdfFunction {
> public static String eval(String a) {
> ...
> }
> public static String eval(String a, String b) {
>
> }
> public static String eval(String a, int c) {
>
> }
> }
> {code}
> {code:java}
> @UDFDescription(name = "MY_UDTF", category =
> SqlFunctionCategory.USER_DEFINED_TABLE_FUNCTION)
> public static class MyUdtfFunction {
> public static MyScannableTable eval(String a) {
> ...
> }
> public static MyScannableTable eval(long a) {
> ...
> }
> public static MyScannableTable eval(int a) {
> ...
> }
> }
> {code}
> This issue wants to improve
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-3000) Improve SqlUserDefinedFunction and SqlUserDefinedTableFunction to support overload method call
[ https://issues.apache.org/jira/browse/CALCITE-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3000: Labels: pull-request-available (was: ) > Improve SqlUserDefinedFunction and SqlUserDefinedTableFunction to support > overload method call > -- > > Key: CALCITE-3000 > URL: https://issues.apache.org/jira/browse/CALCITE-3000 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: pengzhiwei >Assignee: pengzhiwei >Priority: Major > Labels: pull-request-available > > Currently the ModelHandler adds one Function to the schema for one java > method. For the scalar function,ModelHandler resolves all the method in the > class and translate each of them to ScalarFunction to support overload method > call. But for TableFunction, this has not been support yet. > Maybe we can support it as the scalar function does. However in that way, > one sql function may match multiple Functions in the schema.I think this is > not a good way. It is better to have only one Function in the schema for one > sql function just like the BuildIn operator. > I'd like to support a new operand type check strategy for > SqlUserDefinedFunction and SqlUserDefinedTableFunction which can infer the > operand type and return type according to the input parameter types. > I will extend the Types#lookupMethod to support finding the best method in > all of the override methods in a class. And the > SqlReturnTypeInference、SqlOperandTypeInference and > SqlOperandTypeChecker can use this to do the type inference according to the > input types. I think it is a dynamically way compared with the original way. > Any suggestion is welcomed,thanks! > > > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2973) Allow theta joins that have equi conditions to be executed using a hash join algorithm
[ https://issues.apache.org/jira/browse/CALCITE-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822387#comment-16822387 ] Stamatis Zampetakis commented on CALCITE-2973: -- bq. Both EnumerableHashJoin and EnumerableMergeJoin should be extended to be able to deal with non-equijoin, as long as there is a join condition with equality operator and both sides of the operator uses columns from each single relation I think this JIRA/PR are doing the job for EnumerableHashJoin so I guess we could merge it back quite easily. [~hhlai1990], as [~hyuan] said probably the only thing that needs to be changed is instead of creating a new class EnumerableThetaHashJoin you should rather modify EnumerableJoin. The various renamings of joins are in progress in CALCITE-2969, so I don't think we should worry about that here. > Allow theta joins that have equi conditions to be executed using a hash join > algorithm > -- > > Key: CALCITE-2973 > URL: https://issues.apache.org/jira/browse/CALCITE-2973 > Project: Calcite > Issue Type: New Feature > Components: core >Affects Versions: 1.19.0 >Reporter: Lai Zhou >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Now the EnumerableMergeJoinRule only supports an inner and equi join. > If users make a theta-join query for a large dataset (such as 1*1), > the nested-loop join process will take dozens of time than the sort-merge > join process . > So if we can apply merge-join or hash-join rule for a theta join, it will > improve the performance greatly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
