[jira] [Commented] (CALCITE-4191) Improve the logic of creating aggregate calls
[
https://issues.apache.org/jira/browse/CALCITE-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17183742#comment-17183742
]
Julian Hyde commented on CALCITE-4191:
--
Did you consider using RelBuilder? I think it solves this problem.
I wish you would log a JIRA case when you start work, rather than creating a
JIRA case and PR at the same time.
> Improve the logic of creating aggregate calls
> -
>
> Key: CALCITE-4191
> URL: https://issues.apache.org/jira/browse/CALCITE-4191
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Liya Fan
>Assignee: Liya Fan
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> According to the current code base, the only way to create \{{AggregateCall}}
> objects is by calling one of the two \{{AggregateCall#create}} methods (other
> create methods are deprecated).
> The two {{create}} methods have 9 and 11 parameters, respectively, 3 of which
> are booleans and 2 are ints. We find this makes the code less readable and
> error-prone, as some bugs are caused by specifying the wrong parameters.
> In this issue, we improve the related logic by the builder pattern, which
> results in the following benefits:
> 1. By creating the objects by the builder pattern, there is no need to
> maintain multiple overrides of the {{create}} methods.
> 2. There is no need to maintain multiple overrides of the {{copy}} methods,
> either.
> 3. The code becomes more readable and less error-prone, as it is less like to
> specify the wrong parameter.
> 4. Creating {{AggregateCall}} objects becomes easier, as the user does not
> have specify the default parameters repeatedly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4190) OR simplification incorrectly loses term
[
https://issues.apache.org/jira/browse/CALCITE-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-4190.
--
Resolution: Fixed
Fixed in
[401b0189|https://github.com/apache/calcite/commit/401b01897b9a3b588d38acb6459411c5f7805776].
> OR simplification incorrectly loses term
>
>
> Key: CALCITE-4190
> URL: https://issues.apache.org/jira/browse/CALCITE-4190
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.26.0
>
>
> Simplification of OR expressions incorrectly loses a term. For example,
> {code}(0 < a and a <= 10) or a is null or (8 < a and a < 12) or a >= 15{code}
> is simplified to
> {code}as is null or (0 < a and a <= 10) or (8 < a and a < 12){code}
> (Moving {{a is null}} to the front is expected, but removing {{a >= 15}} is
> wrong.)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4191) Improve the logic of creating aggregate calls
[
https://issues.apache.org/jira/browse/CALCITE-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-4191:
Labels: pull-request-available (was: )
> Improve the logic of creating aggregate calls
> -
>
> Key: CALCITE-4191
> URL: https://issues.apache.org/jira/browse/CALCITE-4191
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Liya Fan
>Assignee: Liya Fan
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> According to the current code base, the only way to create \{{AggregateCall}}
> objects is by calling one of the two \{{AggregateCall#create}} methods (other
> create methods are deprecated).
> The two {{create}} methods have 9 and 11 parameters, respectively, 3 of which
> are booleans and 2 are ints. We find this makes the code less readable and
> error-prone, as some bugs are caused by specifying the wrong parameters.
> In this issue, we improve the related logic by the builder pattern, which
> results in the following benefits:
> 1. By creating the objects by the builder pattern, there is no need to
> maintain multiple overrides of the {{create}} methods.
> 2. There is no need to maintain multiple overrides of the {{copy}} methods,
> either.
> 3. The code becomes more readable and less error-prone, as it is less like to
> specify the wrong parameter.
> 4. Creating {{AggregateCall}} objects becomes easier, as the user does not
> have specify the default parameters repeatedly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4191) Improve the logic of creating aggregate calls
Liya Fan created CALCITE-4191:
-
Summary: Improve the logic of creating aggregate calls
Key: CALCITE-4191
URL: https://issues.apache.org/jira/browse/CALCITE-4191
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Liya Fan
Assignee: Liya Fan
According to the current code base, the only way to create \{{AggregateCall}}
objects is by calling one of the two \{{AggregateCall#create}} methods (other
create methods are deprecated).
The two {{create}} methods have 9 and 11 parameters, respectively, 3 of which
are booleans and 2 are ints. We find this makes the code less readable and
error-prone, as some bugs are caused by specifying the wrong parameters.
In this issue, we improve the related logic by the builder pattern, which
results in the following benefits:
1. By creating the objects by the builder pattern, there is no need to maintain
multiple overrides of the {{create}} methods.
2. There is no need to maintain multiple overrides of the {{copy}} methods,
either.
3. The code becomes more readable and less error-prone, as it is less like to
specify the wrong parameter.
4. Creating {{AggregateCall}} objects becomes easier, as the user does not have
specify the default parameters repeatedly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2317) getFunctions() showing empty
[
https://issues.apache.org/jira/browse/CALCITE-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17183688#comment-17183688
]
Danny Chen commented on CALCITE-2317:
-
> Does this schema always exist
I'm afraid no, Calcite now use the {{SqlOperatorTable}} to all builtin
functions. Take {{SqlLibraryOperatorTableFactory}} as a reference to see how to
create different operator table for different SQL dialects.
You may need to create a new Schema impl there or just put the functions in the
result set.
> getFunctions() showing empty
>
>
> Key: CALCITE-2317
> URL: https://issues.apache.org/jira/browse/CALCITE-2317
> Project: Calcite
> Issue Type: Bug
>Reporter: Subbarao
>Assignee: Malte Bellmann
>Priority: Major
> Labels: pull-requests-available
> Attachments: CalciteWithOracle.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> how to get all function names and procedure names in oracle database using
> calcite connection and schema.
> schema.getFunctionNames() return result is:[ ]
> Then i am try to retrieving DatabaseMetadata.getFunction().Here also it will
> be showing empty.
> Iam using calciResultSet ,AvaticaResultSet and ResultSet for getting
> functions and procedures but will be showing empty.
> Is it possible get all function names and procedure names from any database.
> But normal jdbc connection using DatabseMetaData properties it retrive alll
> function names and procedure names.Why it will not retrive in calcite
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4172) SqlValidatorImpl.validateGroupClause should expand identifiers before resolving them against the catalog
[
https://issues.apache.org/jira/browse/CALCITE-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen resolved CALCITE-4172.
-
Fix Version/s: 1.26.0
Assignee: Danny Chen
Resolution: Fixed
Fixed in
[468b111|https://github.com/apache/calcite/commit/468b111b3cae44efd31e60c4bafe0018c8821e9a],
thanks for the PR, [~jamesstarr] ~
> SqlValidatorImpl.validateGroupClause should expand identifiers before
> resolving them against the catalog
>
>
> Key: CALCITE-4172
> URL: https://issues.apache.org/jira/browse/CALCITE-4172
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: James Starr
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.26.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I am attempt to support a Linq style syntax where you can 'dot' into a
> complex element. In order to do this I am attempt to use
> SqlValidatorImpl.expand and related functions to rewrite the columnar
> identifiers before they are validated.
> SqlValidatorImpl.validateGroupClause calls SqlValidatorImpl.inferUnknownTypes
> which attempts to resolve the identifiers against the catalog. Every where
> else that I am aware of first expands the identifier if configured to before
> resolving.
> SqlValidatorImpl.validateGroupClause immediately after calling
> inferUnknownTypes expands the identifiers.
> {code:java}
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4470)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4470)
> at
> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:364)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5220)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5183)
> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:344) at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1602)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1587)
> at
> org.apache.calcite.sql.type.InferTypes$1.inferOperandTypes(InferTypes.java:52)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1773)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1738)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateGroupClause(SqlValidatorImpl.java:3576)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3201)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:943)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:924)
> at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:226){code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3841) Change downloads page to use downloads.apache.org
[
https://issues.apache.org/jira/browse/CALCITE-3841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17183603#comment-17183603
]
Julian Hyde commented on CALCITE-3841:
--
I have set 'fixVersion' to 1.26. Do not clear it. We must do this for 1.26.
> Change downloads page to use downloads.apache.org
> -
>
> Key: CALCITE-3841
> URL: https://issues.apache.org/jira/browse/CALCITE-3841
> Project: Calcite
> Issue Type: Bug
> Components: site
>Reporter: Julian Hyde
>Assignee: Haisheng Yuan
>Priority: Major
> Fix For: 1.26.0
>
>
> Infra has
> [decided|https://lists.apache.org/thread.html/rcd2864e75e417597d342b8eb83080eb2d7a0cafea84fd4521a4d9cfd%40%3Cusers.infra.apache.org%3E]
> (login required for that email link) to deprecate
> [www.apache.org/dist|https://www.apache.org/dist] and move downloads to
> [https://downloads.apache.org|https://downloads.apache.org].
> On [Calcite's downloads page|https://calcite.apache.org/downloads/], we need
> to change the 'digest' link from (for example)
> {{https://www.apache.org/dist/calcite/apache-calcite-1.21.0/apache-calcite-1.21.0-src.tar.gz.sha256}}
> to
> {{https://downloads.apache.org/calcite/apache-calcite-1.21.0/apache-calcite-1.21.0-src.tar.gz.sha256}},
> and similarly the 'gpg' link.
> I believe that the 'tar' link can remain as
> {{https://www.apache.org/dyn/closer.lua?filename=calcite/apache-calcite-1.21.0/apache-calcite-1.21.0-src.tar.gz=download}}
> for the latest release and
> {{https://archive.apache.org/dist/calcite/apache-calcite-1.20.0/apache-calcite-1.20.0-src.tar.gz}}
> for older releases.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3841) Change downloads page to use downloads.apache.org
[
https://issues.apache.org/jira/browse/CALCITE-3841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-3841:
-
Fix Version/s: 1.26.0
> Change downloads page to use downloads.apache.org
> -
>
> Key: CALCITE-3841
> URL: https://issues.apache.org/jira/browse/CALCITE-3841
> Project: Calcite
> Issue Type: Bug
> Components: site
>Reporter: Julian Hyde
>Assignee: Haisheng Yuan
>Priority: Major
> Fix For: 1.26.0
>
>
> Infra has
> [decided|https://lists.apache.org/thread.html/rcd2864e75e417597d342b8eb83080eb2d7a0cafea84fd4521a4d9cfd%40%3Cusers.infra.apache.org%3E]
> (login required for that email link) to deprecate
> [www.apache.org/dist|https://www.apache.org/dist] and move downloads to
> [https://downloads.apache.org|https://downloads.apache.org].
> On [Calcite's downloads page|https://calcite.apache.org/downloads/], we need
> to change the 'digest' link from (for example)
> {{https://www.apache.org/dist/calcite/apache-calcite-1.21.0/apache-calcite-1.21.0-src.tar.gz.sha256}}
> to
> {{https://downloads.apache.org/calcite/apache-calcite-1.21.0/apache-calcite-1.21.0-src.tar.gz.sha256}},
> and similarly the 'gpg' link.
> I believe that the 'tar' link can remain as
> {{https://www.apache.org/dyn/closer.lua?filename=calcite/apache-calcite-1.21.0/apache-calcite-1.21.0-src.tar.gz=download}}
> for the latest release and
> {{https://archive.apache.org/dist/calcite/apache-calcite-1.20.0/apache-calcite-1.20.0-src.tar.gz}}
> for older releases.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3782) Bitwise operator Bit_And, Bit_OR and Bit_XOR support binary and varbinary type
[
https://issues.apache.org/jira/browse/CALCITE-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17183601#comment-17183601
]
Julian Hyde commented on CALCITE-3782:
--
[~hailong wang], Nice work. I have a couple of comments. No need to change
anything.
Why special-case {{byteString.size() == 0}} in {{binaryOperator}}? Zero-length
ByteStrings are not special. But after reading that code, now people think that
they are.
If your goal was to prevent duplicate ByteString values, you could do an
equality check, and it would help other cases besides the corner case.
I see you added the resource to the end of CalciteResource.properties. You may
think that is the polite thing to do. But actually it isn't. It will tend to
conflict with changes from other people who think they are being polite. And it
indicates that you didn't seriously think about the best place to put this
resource in the file. As a rule of thumb, never add stuff to the end of a file.
> Bitwise operator Bit_And, Bit_OR and Bit_XOR support binary and varbinary type
> --
>
> Key: CALCITE-3782
> URL: https://issues.apache.org/jira/browse/CALCITE-3782
> Project: Calcite
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.22.0
>Reporter: hailong wang
>Assignee: hailong wang
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.26.0
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> According to the discussion link CALCITE-3732 , We should make bitwise
> operators work on all integer types, BINARY and VARBINARY. So Bit_And, Bit_OR
> and Bit_XOR agg operator should also support BINARY and VARBINARY.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4183) FilterSetOpTransposeRule constructor should allow for user defined Filter and SetOp classes
[
https://issues.apache.org/jira/browse/CALCITE-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17183597#comment-17183597
]
Julian Hyde commented on CALCITE-4183:
--
I am concerned that if we add the {{withOperandFor(Class filterClass, Class
setOpClass)}} method, someone will want to add a predicate to the filter - e.g.
only allow filters whose condition does not contain the LIKE function - and
will think they need to create a {{withOperandFor(Class filterClass, Predicate
filterPredicate, Class setOpClass)}} method, when actually they can achieve
anything they want by calling the {{withOperandSupplier}} method.
> FilterSetOpTransposeRule constructor should allow for user defined Filter and
> SetOp classes
> ---
>
> Key: CALCITE-4183
> URL: https://issues.apache.org/jira/browse/CALCITE-4183
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.24.0
>Reporter: Sean Broeder
>Priority: Major
> Labels: pull-request-available
> Original Estimate: 168h
> Time Spent: 20m
> Remaining Estimate: 167h 50m
>
> The current FilterSetOpTransposeRule constructor simply takes a
> RelBuilderFactory. Adding an additional constructor would allow more
> flexibility for user specific Filter and SetOp classes and follows behavior
> already allowed for several other rules.
> For example:
> /**
> * Creates a FilterSetOpTransposeRule that uses a generic
> * {@link Filter} and {@link SetOp}
> * @param filterClass filter class
> * @param setOpClass setOp class
> * @param relBuilderFactory builder factory for relational expressions
> */
> public FilterSetOpTransposeRule(Class filterClass,
> Class setOpClass,
> RelBuilderFactory relBuilderFactory) {
>super(
>operand(filterClass,
>operand(setOpClass, any())),
>relBuilderFactory, null);
> }
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4183) FilterSetOpTransposeRule constructor should allow for user defined Filter and SetOp classes
[
https://issues.apache.org/jira/browse/CALCITE-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17183594#comment-17183594
]
Julian Hyde commented on CALCITE-4183:
--
Reviewing the PR.
I am not sure we need this. I am not denying that the fix works. But something
similar could be accomplished in client code without any changes to Calcite.
Without the {{withOperandFor}} method the test case would be 1 or 2 lines
longer - not nothing, is it worth it?
I'm worried that people will think that {{withOperandFor}} methods are the ONLY
way to customize rules. And post CALCITE-3923, they're syntactic sugar but not
necessary.
> FilterSetOpTransposeRule constructor should allow for user defined Filter and
> SetOp classes
> ---
>
> Key: CALCITE-4183
> URL: https://issues.apache.org/jira/browse/CALCITE-4183
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.24.0
>Reporter: Sean Broeder
>Priority: Major
> Labels: pull-request-available
> Original Estimate: 168h
> Time Spent: 20m
> Remaining Estimate: 167h 50m
>
> The current FilterSetOpTransposeRule constructor simply takes a
> RelBuilderFactory. Adding an additional constructor would allow more
> flexibility for user specific Filter and SetOp classes and follows behavior
> already allowed for several other rules.
> For example:
> /**
> * Creates a FilterSetOpTransposeRule that uses a generic
> * {@link Filter} and {@link SetOp}
> * @param filterClass filter class
> * @param setOpClass setOp class
> * @param relBuilderFactory builder factory for relational expressions
> */
> public FilterSetOpTransposeRule(Class filterClass,
> Class setOpClass,
> RelBuilderFactory relBuilderFactory) {
>super(
>operand(filterClass,
>operand(setOpClass, any())),
>relBuilderFactory, null);
> }
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4183) FilterSetOpTransposeRule constructor should allow for user defined Filter and SetOp classes
[
https://issues.apache.org/jira/browse/CALCITE-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-4183:
Labels: pull-request-available (was: )
> FilterSetOpTransposeRule constructor should allow for user defined Filter and
> SetOp classes
> ---
>
> Key: CALCITE-4183
> URL: https://issues.apache.org/jira/browse/CALCITE-4183
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.24.0
>Reporter: Sean Broeder
>Priority: Major
> Labels: pull-request-available
> Original Estimate: 168h
> Time Spent: 20m
> Remaining Estimate: 167h 50m
>
> The current FilterSetOpTransposeRule constructor simply takes a
> RelBuilderFactory. Adding an additional constructor would allow more
> flexibility for user specific Filter and SetOp classes and follows behavior
> already allowed for several other rules.
> For example:
> /**
> * Creates a FilterSetOpTransposeRule that uses a generic
> * {@link Filter} and {@link SetOp}
> * @param filterClass filter class
> * @param setOpClass setOp class
> * @param relBuilderFactory builder factory for relational expressions
> */
> public FilterSetOpTransposeRule(Class filterClass,
> Class setOpClass,
> RelBuilderFactory relBuilderFactory) {
>super(
>operand(filterClass,
>operand(setOpClass, any())),
>relBuilderFactory, null);
> }
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (CALCITE-4183) FilterSetOpTransposeRule constructor should allow for user defined Filter and SetOp classes
[
https://issues.apache.org/jira/browse/CALCITE-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Broeder reopened CALCITE-4183:
---
Reopening so that changes can be reviewed
> FilterSetOpTransposeRule constructor should allow for user defined Filter and
> SetOp classes
> ---
>
> Key: CALCITE-4183
> URL: https://issues.apache.org/jira/browse/CALCITE-4183
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.24.0
>Reporter: Sean Broeder
>Priority: Major
> Original Estimate: 168h
> Time Spent: 10m
> Remaining Estimate: 168h
>
> The current FilterSetOpTransposeRule constructor simply takes a
> RelBuilderFactory. Adding an additional constructor would allow more
> flexibility for user specific Filter and SetOp classes and follows behavior
> already allowed for several other rules.
> For example:
> /**
> * Creates a FilterSetOpTransposeRule that uses a generic
> * {@link Filter} and {@link SetOp}
> * @param filterClass filter class
> * @param setOpClass setOp class
> * @param relBuilderFactory builder factory for relational expressions
> */
> public FilterSetOpTransposeRule(Class filterClass,
> Class setOpClass,
> RelBuilderFactory relBuilderFactory) {
>super(
>operand(filterClass,
>operand(setOpClass, any())),
>relBuilderFactory, null);
> }
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4183) FilterSetOpTransposeRule constructor should allow for user defined Filter and SetOp classes
[
https://issues.apache.org/jira/browse/CALCITE-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Broeder updated CALCITE-4183:
--
Labels: (was: pull-request-available)
Remaining Estimate: 168h (was: 167h 50m)
I believe FilterSetOpTranspose.java was missing the withOperandFor method that
allows custom classes to be used
final FilterSetOpTransposeRule filterSetOpTransposeRule =
FilterSetOpTransposeRule.Config.DEFAULT
.withOperandFor(MyFilter.class, MySetOp.class)
.toRule();
I have created a PR #2119 that implements and tests this.
> FilterSetOpTransposeRule constructor should allow for user defined Filter and
> SetOp classes
> ---
>
> Key: CALCITE-4183
> URL: https://issues.apache.org/jira/browse/CALCITE-4183
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.24.0
>Reporter: Sean Broeder
>Priority: Major
> Original Estimate: 168h
> Time Spent: 10m
> Remaining Estimate: 168h
>
> The current FilterSetOpTransposeRule constructor simply takes a
> RelBuilderFactory. Adding an additional constructor would allow more
> flexibility for user specific Filter and SetOp classes and follows behavior
> already allowed for several other rules.
> For example:
> /**
> * Creates a FilterSetOpTransposeRule that uses a generic
> * {@link Filter} and {@link SetOp}
> * @param filterClass filter class
> * @param setOpClass setOp class
> * @param relBuilderFactory builder factory for relational expressions
> */
> public FilterSetOpTransposeRule(Class filterClass,
> Class setOpClass,
> RelBuilderFactory relBuilderFactory) {
>super(
>operand(filterClass,
>operand(setOpClass, any())),
>relBuilderFactory, null);
> }
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4183) FilterSetOpTransposeRule constructor should allow for user defined Filter and SetOp classes
[
https://issues.apache.org/jira/browse/CALCITE-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-4183:
Labels: pull-request-available (was: )
> FilterSetOpTransposeRule constructor should allow for user defined Filter and
> SetOp classes
> ---
>
> Key: CALCITE-4183
> URL: https://issues.apache.org/jira/browse/CALCITE-4183
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.24.0
>Reporter: Sean Broeder
>Priority: Major
> Labels: pull-request-available
> Original Estimate: 168h
> Time Spent: 10m
> Remaining Estimate: 167h 50m
>
> The current FilterSetOpTransposeRule constructor simply takes a
> RelBuilderFactory. Adding an additional constructor would allow more
> flexibility for user specific Filter and SetOp classes and follows behavior
> already allowed for several other rules.
> For example:
> /**
> * Creates a FilterSetOpTransposeRule that uses a generic
> * {@link Filter} and {@link SetOp}
> * @param filterClass filter class
> * @param setOpClass setOp class
> * @param relBuilderFactory builder factory for relational expressions
> */
> public FilterSetOpTransposeRule(Class filterClass,
> Class setOpClass,
> RelBuilderFactory relBuilderFactory) {
>super(
>operand(filterClass,
>operand(setOpClass, any())),
>relBuilderFactory, null);
> }
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4113) Support LEFT join in EnumerableMergeJoin
[ https://issues.apache.org/jira/browse/CALCITE-4113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ruben Q L resolved CALCITE-4113. Resolution: Fixed Fixed via https://github.com/apache/calcite/commit/672ed7a1d0dbf87760d37e52b424f16bc8c43b4d > Support LEFT join in EnumerableMergeJoin > > > Key: CALCITE-4113 > URL: https://issues.apache.org/jira/browse/CALCITE-4113 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Ruben Q L >Assignee: Ruben Q L >Priority: Major > Labels: pull-request-available > Fix For: 1.26.0 > > Time Spent: 3.5h > Remaining Estimate: 0h > > Currently, EnumerableMergeJoin supports INNER, SEMI, and ANTI join. > The goal of this ticket is to support also LEFT join (which should be a > combination of INNER join results + ANTI join results with a NULL on the > right). > LEFT EnumerableMergeJoin should maintain the order of the left-hand-side of > the join. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-2317) getFunctions() showing empty
[
https://issues.apache.org/jira/browse/CALCITE-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17183067#comment-17183067
]
Malte Bellmann commented on CALCITE-2317:
-
{quote}Just curious, the {{Calcite.getFunctions}} only return the registered
UDFs, is this the standard behavior, or what should we expect to return for
{{DatabaseMetadata.getFunction()}} ?
{quote}
Thanks [~danny0405], good point!
According to the specification
[https://docs.oracle.com/en/java/javase/14/docs/api/java.sql/java/sql/DatabaseMetaData.html#getFunctions(java.lang.String,java.lang.String,java.lang.String)]
"system and user functions available in the given catalog" should be returned.
Therefore, in theory, all build-in functions must be returned as well.
Postgres for example has a schema "pg_catalog" where all these functions
reside.
We could add all build-in functions to the "metadata" schema.
1) Does this schema always exist?
2) Where would I find all build-in functions?
> getFunctions() showing empty
>
>
> Key: CALCITE-2317
> URL: https://issues.apache.org/jira/browse/CALCITE-2317
> Project: Calcite
> Issue Type: Bug
>Reporter: Subbarao
>Assignee: Malte Bellmann
>Priority: Major
> Labels: pull-requests-available
> Attachments: CalciteWithOracle.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> how to get all function names and procedure names in oracle database using
> calcite connection and schema.
> schema.getFunctionNames() return result is:[ ]
> Then i am try to retrieving DatabaseMetadata.getFunction().Here also it will
> be showing empty.
> Iam using calciResultSet ,AvaticaResultSet and ResultSet for getting
> functions and procedures but will be showing empty.
> Is it possible get all function names and procedure names from any database.
> But normal jdbc connection using DatabseMetaData properties it retrive alll
> function names and procedure names.Why it will not retrive in calcite
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4113) Support LEFT join in EnumerableMergeJoin
[ https://issues.apache.org/jira/browse/CALCITE-4113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ruben Q L updated CALCITE-4113: --- Fix Version/s: 1.26.0 > Support LEFT join in EnumerableMergeJoin > > > Key: CALCITE-4113 > URL: https://issues.apache.org/jira/browse/CALCITE-4113 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Ruben Q L >Assignee: Ruben Q L >Priority: Major > Labels: pull-request-available > Fix For: 1.26.0 > > Time Spent: 3h > Remaining Estimate: 0h > > Currently, EnumerableMergeJoin supports INNER, SEMI, and ANTI join. > The goal of this ticket is to support also LEFT join (which should be a > combination of INNER join results + ANTI join results with a NULL on the > right). > LEFT EnumerableMergeJoin should maintain the order of the left-hand-side of > the join. -- This message was sent by Atlassian Jira (v8.3.4#803005)
