[jira] [Commented] (CALCITE-2342) use of assert with side-effect in Schemas
[
https://issues.apache.org/jira/browse/CALCITE-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16496111#comment-16496111
]
Laurent Goujon commented on CALCITE-2342:
-
Also run all tests with assertions disabled, and it's the only one I found
triggering test failures...
> use of assert with side-effect in Schemas
> -
>
> Key: CALCITE-2342
> URL: https://issues.apache.org/jira/browse/CALCITE-2342
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Laurent Goujon
>Assignee: Laurent Goujon
>Priority: Major
>
> {{Schemas#path(CalciteSchema,Iterable)}} method has the following
> code:
> {code:java}
> if (!rootSchema.name.isEmpty()) {
> assert rootSchema.name.equals(iterator.next());
> }
> {code}
> Depending if assertions are enabled or not, iterator state might be different
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2342) use of assert with side-effect in Schemas
[
https://issues.apache.org/jira/browse/CALCITE-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16496109#comment-16496109
]
Laurent Goujon commented on CALCITE-2342:
-
I posted a github PR (actually for multiple JIRAs) but I don't see it linked.
Did I mess up my comment message and cause the integration not to work?
https://github.com/apache/calcite/pull/712
> use of assert with side-effect in Schemas
> -
>
> Key: CALCITE-2342
> URL: https://issues.apache.org/jira/browse/CALCITE-2342
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Laurent Goujon
>Assignee: Laurent Goujon
>Priority: Major
>
> {{Schemas#path(CalciteSchema,Iterable)}} method has the following
> code:
> {code:java}
> if (!rootSchema.name.isEmpty()) {
> assert rootSchema.name.equals(iterator.next());
> }
> {code}
> Depending if assertions are enabled or not, iterator state might be different
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2344) Wrong constant reduction over windows function
[
https://issues.apache.org/jira/browse/CALCITE-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16496106#comment-16496106
]
Laurent Goujon commented on CALCITE-2344:
-
but empty is not null?
> Wrong constant reduction over windows function
> --
>
> Key: CALCITE-2344
> URL: https://issues.apache.org/jira/browse/CALCITE-2344
> Project: Calcite
> Issue Type: Bug
>Reporter: Laurent Goujon
>Assignee: Laurent Goujon
>Priority: Major
>
> {{RexUtil}} might incorrectly infer a IS NULL predicate would cause a
> reference over a window function to return null, but a window function type
> is never nullable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2345) add tests using Fongo to Mongo Adapter
[
https://issues.apache.org/jira/browse/CALCITE-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16496102#comment-16496102
]
Andrei Sereda edited comment on CALCITE-2345 at 5/31/18 5:06 AM:
-
If you enable system property
[fongo.force.realMongo|https://github.com/fakemongo/fongo/blob/master/src/main/java/com/github/fakemongo/junit/FongoRule.java#L69]
it will automatically connect to default mongo instance ({{localhost:27017}}).
Another question is how the database should be populated: same as IT (with
{{zips.json}}) or manually.
was (Author: asereda):
If you enable system property
[fongo.force.realMongo|https://github.com/fakemongo/fongo/blob/master/src/main/java/com/github/fakemongo/junit/FongoRule.java#L69]
it will automatically connect to default mongo instance ({{localhost:27017}})
> add tests using Fongo to Mongo Adapter
> --
>
> Key: CALCITE-2345
> URL: https://issues.apache.org/jira/browse/CALCITE-2345
> Project: Calcite
> Issue Type: Improvement
>Reporter: Andrei Sereda
>Assignee: Julian Hyde
>Priority: Major
>
> Better test coverage for unit tests using
> [Fongo|https://github.com/fakemongo/fongo] which is in-memory implementation
> of Mongo API.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2345) add tests using Fongo to Mongo Adapter
[
https://issues.apache.org/jira/browse/CALCITE-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16496102#comment-16496102
]
Andrei Sereda commented on CALCITE-2345:
If you enable system property
[fongo.force.realMongo|https://github.com/fakemongo/fongo/blob/master/src/main/java/com/github/fakemongo/junit/FongoRule.java#L69]
it will automatically connect to default mongo instance ({{localhost:27017}})
> add tests using Fongo to Mongo Adapter
> --
>
> Key: CALCITE-2345
> URL: https://issues.apache.org/jira/browse/CALCITE-2345
> Project: Calcite
> Issue Type: Improvement
>Reporter: Andrei Sereda
>Assignee: Julian Hyde
>Priority: Major
>
> Better test coverage for unit tests using
> [Fongo|https://github.com/fakemongo/fongo] which is in-memory implementation
> of Mongo API.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2336) SqlValidatorImpl throws java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CALCITE-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16496093#comment-16496093
]
Julian Hyde commented on CALCITE-2336:
--
In which case, sorry, I have no idea.
> SqlValidatorImpl throws java.lang.IndexOutOfBoundsException
> ---
>
> Key: CALCITE-2336
> URL: https://issues.apache.org/jira/browse/CALCITE-2336
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Fei Xu
>Assignee: Julian Hyde
>Priority: Major
>
> I register a table "users" with a single column, age. And try to insert two
> columns into the "users".
> {code:java}
> rootSchema = Frameworks.createRootSchema(true);
> rootSchema.add("USERS", new AbstractTable() {
> @Override public RelDataType getRowType(final RelDataTypeFactory
> typeFactory) {
> RelDataTypeFactory.FieldInfoBuilder builder = typeFactory.builder();
> builder.add("age", new BasicSqlType(new RelDataTypeSystemImpl() {},
> SqlTypeName.CHAR));
> return builder.build();
> }
> });
> final FrameworkConfig config = Frameworks.newConfigBuilder()
> .parserConfig(SqlParser.Config.DEFAULT)
> .defaultSchema(rootSchema)
> .build();
> planner = Frameworks.getPlanner(config);
> dataContext = new MyDataContext(planner);
> SqlNode parse =
> planner.parse("insert into users select y, x\n"
> + "from (values (1, 'a'), (2, 'b'), (3, 'c')) as t(x, y)\n"
> + "where x > 1");
> SqlNode validate = planner.validate(parse);
> {code}
> Apparently, I want to see some error message like:
> {code:java}
> Number of INSERT target columns (1) does not equal number of source items (2)
> {code}
> But actually, I got message:
> {code:java}
> org.apache.calcite.tools.ValidationException:
> java.lang.IndexOutOfBoundsException: index (1) must be less than size (1)
> {code}
> which was confused.
> Then I debug the code in SqlValidatorImpl#validateSelectList method.
>
> {code:java}
> protected RelDataType validateSelectList(
> final SqlNodeList selectItems,
> SqlSelect select,
> RelDataType targetRowType) {
> // First pass, ensure that aliases are unique. "*" and "TABLE.*" items
> // are ignored.
> // Validate SELECT list. Expand terms of the form "*" or "TABLE.*".
> final SqlValidatorScope selectScope = getSelectScope(select);
> final List expandedSelectItems = new ArrayList<>();
> final Set aliases = Sets.newHashSet();
> final List> fieldList = new ArrayList<>();
> for (int i = 0; i < selectItems.size(); i++) {
> SqlNode selectItem = selectItems.get(i);
> if (selectItem instanceof SqlSelect) {
> handleScalarSubQuery(
> select,
> (SqlSelect) selectItem,
> expandedSelectItems,
> aliases,
> fieldList);
> } else {
> expandSelectItem(
> selectItem,
> select,
> targetRowType.isStruct()
> && targetRowType.getFieldCount() >= i
> ? targetRowType.getFieldList().get(i).getType()
> : unknownType,
> expandedSelectItems,
> aliases,
> fieldList,
> false);
> }
> }
> {code}
> See the exception is throw from here, if selectItems's size more than
> targetRowType's field count
> {code:java}
> && targetRowType.getFieldCount() >= i
> ? targetRowType.getFieldList().get(i).getType(){code}
> When I change it to this, I get what I need.
> {code:java}
> && targetRowType.getFieldCount() - 1 >= i
> ? targetRowType.getFieldList().get(i).getType(){code}
> So is this a Bug ? Do we need fix it ?
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2342) use of assert with side-effect in Schemas
[
https://issues.apache.org/jira/browse/CALCITE-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16496091#comment-16496091
]
Julian Hyde commented on CALCITE-2342:
--
Nice catch.
> use of assert with side-effect in Schemas
> -
>
> Key: CALCITE-2342
> URL: https://issues.apache.org/jira/browse/CALCITE-2342
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Laurent Goujon
>Assignee: Laurent Goujon
>Priority: Major
>
> {{Schemas#path(CalciteSchema,Iterable)}} method has the following
> code:
> {code:java}
> if (!rootSchema.name.isEmpty()) {
> assert rootSchema.name.equals(iterator.next());
> }
> {code}
> Depending if assertions are enabled or not, iterator state might be different
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2344) Wrong constant reduction over windows function
[
https://issues.apache.org/jira/browse/CALCITE-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16496081#comment-16496081
]
Julian Hyde commented on CALCITE-2344:
--
Not true. Windows can be empty, e.g. {{BETWEEN INTERVAL '2' MINUTE PRECEDING
AND INTERVAL '1' PRECEDING}}.
> Wrong constant reduction over windows function
> --
>
> Key: CALCITE-2344
> URL: https://issues.apache.org/jira/browse/CALCITE-2344
> Project: Calcite
> Issue Type: Bug
>Reporter: Laurent Goujon
>Assignee: Laurent Goujon
>Priority: Major
>
> {{RexUtil}} might incorrectly infer a IS NULL predicate would cause a
> reference over a window function to return null, but a window function type
> is never nullable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2345) add tests using Fongo to Mongo Adapter
[ https://issues.apache.org/jira/browse/CALCITE-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16496079#comment-16496079 ] Julian Hyde commented on CALCITE-2345: -- This would definitely be useful. Would it be possible to run the same test of tests against either Fongo or the real Mongo, based on a runtime parameter? The tests could be run against Fongo every time, and run against Mongo when we run integration tests (which, sadly, is not often enough). > add tests using Fongo to Mongo Adapter > -- > > Key: CALCITE-2345 > URL: https://issues.apache.org/jira/browse/CALCITE-2345 > Project: Calcite > Issue Type: Improvement >Reporter: Andrei Sereda >Assignee: Julian Hyde >Priority: Major > > Better test coverage for unit tests using > [Fongo|https://github.com/fakemongo/fongo] which is in-memory implementation > of Mongo API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2345) add tests using Fongo to Mongo Adapter
Andrei Sereda created CALCITE-2345: -- Summary: add tests using Fongo to Mongo Adapter Key: CALCITE-2345 URL: https://issues.apache.org/jira/browse/CALCITE-2345 Project: Calcite Issue Type: Improvement Reporter: Andrei Sereda Assignee: Julian Hyde Better test coverage for unit tests using [Fongo|https://github.com/fakemongo/fongo] which is in-memory implementation of Mongo API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2344) Wrong constant reduction over windows function
Laurent Goujon created CALCITE-2344:
---
Summary: Wrong constant reduction over windows function
Key: CALCITE-2344
URL: https://issues.apache.org/jira/browse/CALCITE-2344
Project: Calcite
Issue Type: Bug
Reporter: Laurent Goujon
Assignee: Laurent Goujon
{{RexUtil}} might incorrectly infer a IS NULL predicate would cause a reference
over a window function to return null, but a window function type is never
nullable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2343) PushProjector with OVER expression causing infinite loop
Laurent Goujon created CALCITE-2343:
---
Summary: PushProjector with OVER expression causing infinite loop
Key: CALCITE-2343
URL: https://issues.apache.org/jira/browse/CALCITE-2343
Project: Calcite
Issue Type: Bug
Reporter: Laurent Goujon
Assignee: Laurent Goujon
When applying the {{ProjectJoinTransposeRule}} on a project with a Rex
expression containing a RexOver call (using HepPlanner), this might cause an
infinite loop (and ultimately a StackOverflowError exception) as PushProjector
identify the RexOver call as to be push down under the join, but doesn't not
rewrite correctly the top Project expression.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2342) use of assert with side-effect in Schemas
Laurent Goujon created CALCITE-2342:
---
Summary: use of assert with side-effect in Schemas
Key: CALCITE-2342
URL: https://issues.apache.org/jira/browse/CALCITE-2342
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Laurent Goujon
Assignee: Laurent Goujon
{{Schemas#path(CalciteSchema,Iterable)}} method has the following code:
{code:java}
if (!rootSchema.name.isEmpty()) {
assert rootSchema.name.equals(iterator.next());
}
{code}
Depending if assertions are enabled or not, iterator state might be different
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2336) SqlValidatorImpl throws java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CALCITE-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16496013#comment-16496013
]
Fei Xu commented on CALCITE-2336:
-
Hi Julian, I change the code, e.g. but it seems doesn't help.
{code:java}
rootSchema = Frameworks.createRootSchema(true);
rootSchema.add("USERS", new AbstractTable() {
@Override public RelDataType getRowType(final RelDataTypeFactory
typeFactory) {
RelDataTypeFactory.FieldInfoBuilder builder = typeFactory.builder();
//builder.add("name", new BasicSqlType(new RelDataTypeSystemImpl() {},
SqlTypeName.BIGINT));
builder.add("name", typeFactory.createSqlType(SqlTypeName.BIGINT));
return builder.build();
}
});
final FrameworkConfig config = Frameworks.newConfigBuilder()
.parserConfig(SqlParser.Config.DEFAULT)
.defaultSchema(rootSchema)
.build();
planner = Frameworks.getPlanner(config);
dataContext = new MyDataContext(planner);
SqlNode parse =
planner.parse("insert into users select y, x\n"
+ "from (values (1, 'a'), (2, 'b'), (3, 'c')) as t(x, y)\n"
+ "where x > 1");
SqlNode validate = planner.validate(parse);
RelNode convert = planner.rel(validate).rel;
{code}
I still get the message
{code:java}
Caused by: java.lang.IndexOutOfBoundsException: index (1) must be less than
size (1)
at
com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:310)
at
com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:293)
at
com.google.common.collect.SingletonImmutableList.get(SingletonImmutableList.java:41)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:3993)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3251)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateInsert(SqlValidatorImpl.java:4165)
at org.apache.calcite.sql.SqlInsert.validate(SqlInsert.java:148)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:915)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:625)
at org.apache.calcite.prepare.PlannerImpl.validate(PlannerImpl.java:194)
... 25 more
{code}
> SqlValidatorImpl throws java.lang.IndexOutOfBoundsException
> ---
>
> Key: CALCITE-2336
> URL: https://issues.apache.org/jira/browse/CALCITE-2336
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Fei Xu
>Assignee: Julian Hyde
>Priority: Major
>
> I register a table "users" with a single column, age. And try to insert two
> columns into the "users".
> {code:java}
> rootSchema = Frameworks.createRootSchema(true);
> rootSchema.add("USERS", new AbstractTable() {
> @Override public RelDataType getRowType(final RelDataTypeFactory
> typeFactory) {
> RelDataTypeFactory.FieldInfoBuilder builder = typeFactory.builder();
> builder.add("age", new BasicSqlType(new RelDataTypeSystemImpl() {},
> SqlTypeName.CHAR));
> return builder.build();
> }
> });
> final FrameworkConfig config = Frameworks.newConfigBuilder()
> .parserConfig(SqlParser.Config.DEFAULT)
> .defaultSchema(rootSchema)
> .build();
> planner = Frameworks.getPlanner(config);
> dataContext = new MyDataContext(planner);
> SqlNode parse =
> planner.parse("insert into users select y, x\n"
> + "from (values (1, 'a'), (2, 'b'), (3, 'c')) as t(x, y)\n"
> + "where x > 1");
> SqlNode validate = planner.validate(parse);
> {code}
> Apparently, I want to see some error message like:
> {code:java}
> Number of INSERT target columns (1) does not equal number of source items (2)
> {code}
> But actually, I got message:
> {code:java}
> org.apache.calcite.tools.ValidationException:
> java.lang.IndexOutOfBoundsException: index (1) must be less than size (1)
> {code}
> which was confused.
> Then I debug the code in SqlValidatorImpl#validateSelectList method.
>
> {code:java}
> protected RelDataType validateSelectList(
> final SqlNodeList selectItems,
> SqlSelect select,
> RelDataType targetRowType) {
> // First pass, ensure that aliases are unique. "*" and "TABLE.*" items
> // are ignored.
> // Validate SELECT list. Expand terms of the form "*" or "TABLE.*".
> final SqlValidatorScope selectScope = getSelectScope(select);
> final List expandedSelectItems = new ArrayList<>();
> final Set aliases = Sets.newHashSet();
> final List> fieldList = new ArrayList<>();
> for (int i = 0; i < selectItems.size(); i++) {
> SqlNode selectItem = selectItems.get(i);
> if (selectItem instanceof SqlSelect) {
>
[jira] [Created] (CALCITE-2341) ImmutableBitSetTest fails with JDK11
Laurent Goujon created CALCITE-2341: --- Summary: ImmutableBitSetTest fails with JDK11 Key: CALCITE-2341 URL: https://issues.apache.org/jira/browse/CALCITE-2341 Project: Calcite Issue Type: Bug Components: core Reporter: Laurent Goujon Assignee: Laurent Goujon A error message change in JDK11 causes ImmutableBitSetTest to fail -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2340) Invalid cast generated by AvgVarianceConvertlet
Laurent Goujon created CALCITE-2340:
---
Summary: Invalid cast generated by AvgVarianceConvertlet
Key: CALCITE-2340
URL: https://issues.apache.org/jira/browse/CALCITE-2340
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Laurent Goujon
Assignee: Laurent Goujon
A bug in {{AvgVarianceConvertlet}} causes {{CAST}} calls to be generated with
the wrong number of arguments if the return type of the aggregation function is
different from the operand.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2302) Implicit type cast support
[
https://issues.apache.org/jira/browse/CALCITE-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495975#comment-16495975
]
Yuzhao Chen commented on CALCITE-2302:
--
Hi, [~julianhyde]
Can you give me some suggestions? I'm really appreciate for it.
This is design doc: [Calcite Implicit Type Cast
Design|https://docs.google.com/document/d/1g2RUnLXyp_LjUlO-wbblKuP5hqEu3a_2Mt2k4dh6RwU/edit?usp=sharing].
This is the conversion types mapping: [Conversion Types
Mapping|https://docs.google.com/spreadsheets/d/1GhleX5h5W8-kJKh7NMJ4vtoE78pwfaZRJl88ULX_MgU/edit?usp=sharing].
> Implicit type cast support
> --
>
> Key: CALCITE-2302
> URL: https://issues.apache.org/jira/browse/CALCITE-2302
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: Yuzhao Chen
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> Now many DBs have support implicit type cast, eg: SqlServer, Oracle, Hive.
> Implicit type cast is an useful function for many cases, So we should support
> this.
> I checkout Calcite code and found that:
> # Now we use a validator to validate our operands types[ through kinds of
> namespaces and scopes ]
> # Most of the validations will finally goes to
> {code:java}
> SqlOperator.validateOperands
> {code}
> # which will use validation logic defined in corresponding
> SqlOperandTypeChecker
> What i'm confused about is where should i put the implicit type cast logic
> in? I figured out 2 ways:
> # Supply a tool class/rules to add casts into a parsed SqlNode tree which
> will then go through the validation logic later on.
> # Unleash the validation logic in kinds of SqlOperandTypeChecker, then
> modify the RelNode/RexNodes tree converted from a validated SqlNode tree to
> add in casts through custom RelOptRules.
> So guys, which of the 2 ways should i go, or if there are better way to do
> this?
> I need your help.
>
> Updated 18-05-30:
> Hi guys, i have made a PR in [https://github.com/apache/calcite/pull/706,]
> This is design doc: [Calcite Implicit Type Cast
> Design|https://docs.google.com/document/d/1g2RUnLXyp_LjUlO-wbblKuP5hqEu3a_2Mt2k4dh6RwU/edit?usp=sharing].
> This is the conversion types mapping: [Conversion Types
> Mapping|https://docs.google.com/spreadsheets/d/1GhleX5h5W8-kJKh7NMJ4vtoE78pwfaZRJl88ULX_MgU/edit?usp=sharing].
> I really appreciate your suggestions, thx.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2303) Support DECADE time unit in EXTRACT function
[
https://issues.apache.org/jira/browse/CALCITE-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495942#comment-16495942
]
Laurent Goujon commented on CALCITE-2303:
-
{quote}
Actually, we do. You guys. When you write tests or code, please push them
upstream. Then we'll be in sync, and we won't need extra engineering effort to
deal with drift.{
{quote}
Thanks for reminding me about that. Oh wait:
https://github.com/apache/calcite/commit/94cb577898e0cab2c1acc92a981133323918660c
{quote}
I'm seeing the old open-core anti-pattern: adding hooks into the open source
version so that it can be more shitty than the enterprise version. Let's not do
that.
{quote}
I cannot comment on my employer policy. But in that specific case, our core
execution engine and the extract/datetime functions are fully open source
> Support DECADE time unit in EXTRACT function
>
>
> Key: CALCITE-2303
> URL: https://issues.apache.org/jira/browse/CALCITE-2303
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Sergey Nuyanzin
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> Here CALCITE-1177 were supported new units
> however such test
> {code:java}
> @Test public void testDecadeFunction() throws Exception {
> ExpressionChecker checker = new ExpressionChecker()
> .addExpr("EXTRACT(DECADE FROM ts)", 199L)
> ;
> checker.buildRunAndCheck();
> }
> {code}
> failed like
> Extract for time unit: DECADE not supported!
> {noformat}
> SQL:>
> SELECT EXTRACT(DECADE FROM ts) FROM PCOLLECTION
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> validateAndConvert
> INFO: SQL:
> SELECT EXTRACT(DECADE FROM `PCOLLECTION`.`ts`)
> FROM `PCOLLECTION` AS `PCOLLECTION`
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> convertToBeamRel
> INFO: SQLPlan>
> LogicalProject(EXPR$0=[EXTRACT(FLAG(DECADE), $0)])
> BeamIOSourceRel(table=[[PCOLLECTION]])
> java.lang.RuntimeException:
> org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
> supported!
> at
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlBuiltinFunctionsIntegrationTestBase$ExpressionChecker.buildRunAndCheck(BeamSqlBuiltinFunctionsIntegrationTestBase.java:167)
> at
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlDateFunctionsIntegrationTest.testDecadeFunction(BeamSqlDateFunctionsIntegrationTest.java:66)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.beam.sdk.testing.TestPipeline$1.evaluate(TestPipeline.java:317)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
> supported!
> at
>
[jira] [Commented] (CALCITE-2336) SqlValidatorImpl throws java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CALCITE-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495941#comment-16495941
]
Fei Xu commented on CALCITE-2336:
-
thanks julian，I’ll try this way
Julian Hyde (JIRA) 于2018年5月31日 周四上午6:31写道：
> SqlValidatorImpl throws java.lang.IndexOutOfBoundsException
> ---
>
> Key: CALCITE-2336
> URL: https://issues.apache.org/jira/browse/CALCITE-2336
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Fei Xu
>Assignee: Julian Hyde
>Priority: Major
>
> I register a table "users" with a single column, age. And try to insert two
> columns into the "users".
> {code:java}
> rootSchema = Frameworks.createRootSchema(true);
> rootSchema.add("USERS", new AbstractTable() {
> @Override public RelDataType getRowType(final RelDataTypeFactory
> typeFactory) {
> RelDataTypeFactory.FieldInfoBuilder builder = typeFactory.builder();
> builder.add("age", new BasicSqlType(new RelDataTypeSystemImpl() {},
> SqlTypeName.CHAR));
> return builder.build();
> }
> });
> final FrameworkConfig config = Frameworks.newConfigBuilder()
> .parserConfig(SqlParser.Config.DEFAULT)
> .defaultSchema(rootSchema)
> .build();
> planner = Frameworks.getPlanner(config);
> dataContext = new MyDataContext(planner);
> SqlNode parse =
> planner.parse("insert into users select y, x\n"
> + "from (values (1, 'a'), (2, 'b'), (3, 'c')) as t(x, y)\n"
> + "where x > 1");
> SqlNode validate = planner.validate(parse);
> {code}
> Apparently, I want to see some error message like:
> {code:java}
> Number of INSERT target columns (1) does not equal number of source items (2)
> {code}
> But actually, I got message:
> {code:java}
> org.apache.calcite.tools.ValidationException:
> java.lang.IndexOutOfBoundsException: index (1) must be less than size (1)
> {code}
> which was confused.
> Then I debug the code in SqlValidatorImpl#validateSelectList method.
>
> {code:java}
> protected RelDataType validateSelectList(
> final SqlNodeList selectItems,
> SqlSelect select,
> RelDataType targetRowType) {
> // First pass, ensure that aliases are unique. "*" and "TABLE.*" items
> // are ignored.
> // Validate SELECT list. Expand terms of the form "*" or "TABLE.*".
> final SqlValidatorScope selectScope = getSelectScope(select);
> final List expandedSelectItems = new ArrayList<>();
> final Set aliases = Sets.newHashSet();
> final List> fieldList = new ArrayList<>();
> for (int i = 0; i < selectItems.size(); i++) {
> SqlNode selectItem = selectItems.get(i);
> if (selectItem instanceof SqlSelect) {
> handleScalarSubQuery(
> select,
> (SqlSelect) selectItem,
> expandedSelectItems,
> aliases,
> fieldList);
> } else {
> expandSelectItem(
> selectItem,
> select,
> targetRowType.isStruct()
> && targetRowType.getFieldCount() >= i
> ? targetRowType.getFieldList().get(i).getType()
> : unknownType,
> expandedSelectItems,
> aliases,
> fieldList,
> false);
> }
> }
> {code}
> See the exception is throw from here, if selectItems's size more than
> targetRowType's field count
> {code:java}
> && targetRowType.getFieldCount() >= i
> ? targetRowType.getFieldList().get(i).getType(){code}
> When I change it to this, I get what I need.
> {code:java}
> && targetRowType.getFieldCount() - 1 >= i
> ? targetRowType.getFieldList().get(i).getType(){code}
> So is this a Bug ? Do we need fix it ?
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2303) Support DECADE time unit in EXTRACT function
[
https://issues.apache.org/jira/browse/CALCITE-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495931#comment-16495931
]
Julian Hyde commented on CALCITE-2303:
--
I'm seeing the old open-core anti-pattern: adding hooks into the open source
version so that it can be more shitty than the enterprise version. Let's not do
that.
> Support DECADE time unit in EXTRACT function
>
>
> Key: CALCITE-2303
> URL: https://issues.apache.org/jira/browse/CALCITE-2303
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Sergey Nuyanzin
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> Here CALCITE-1177 were supported new units
> however such test
> {code:java}
> @Test public void testDecadeFunction() throws Exception {
> ExpressionChecker checker = new ExpressionChecker()
> .addExpr("EXTRACT(DECADE FROM ts)", 199L)
> ;
> checker.buildRunAndCheck();
> }
> {code}
> failed like
> Extract for time unit: DECADE not supported!
> {noformat}
> SQL:>
> SELECT EXTRACT(DECADE FROM ts) FROM PCOLLECTION
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> validateAndConvert
> INFO: SQL:
> SELECT EXTRACT(DECADE FROM `PCOLLECTION`.`ts`)
> FROM `PCOLLECTION` AS `PCOLLECTION`
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> convertToBeamRel
> INFO: SQLPlan>
> LogicalProject(EXPR$0=[EXTRACT(FLAG(DECADE), $0)])
> BeamIOSourceRel(table=[[PCOLLECTION]])
> java.lang.RuntimeException:
> org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
> supported!
> at
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlBuiltinFunctionsIntegrationTestBase$ExpressionChecker.buildRunAndCheck(BeamSqlBuiltinFunctionsIntegrationTestBase.java:167)
> at
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlDateFunctionsIntegrationTest.testDecadeFunction(BeamSqlDateFunctionsIntegrationTest.java:66)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.beam.sdk.testing.TestPipeline$1.evaluate(TestPipeline.java:317)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
> supported!
> at
> org.apache.beam.runners.direct.DirectRunner$DirectPipelineResult.waitUntilFinish(DirectRunner.java:349)
> at
> org.apache.beam.runners.direct.DirectRunner$DirectPipelineResult.waitUntilFinish(DirectRunner.java:319)
> at
> org.apache.beam.runners.direct.DirectRunner.run(DirectRunner.java:210)
> at org.apache.beam.runners.direct.DirectRunner.run(DirectRunner.java:66)
> at org.apache.beam.sdk.Pipeline.run(Pipeline.java:311)
> at
[jira] [Commented] (CALCITE-2303) Support DECADE time unit in EXTRACT function
[
https://issues.apache.org/jira/browse/CALCITE-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495928#comment-16495928
]
Julian Hyde commented on CALCITE-2303:
--
We (the Calcite community) didn't choose to follow a different standard than
Dremio. We just didn't notice that our view of the standard is wrong.
Why? Because we don't have anyone in the community actively working on ODBC
compatibility tests.
Actually, we do. You guys. When you write tests or code, please push them
upstream. Then we'll be in sync, and we won't need extra engineering effort to
deal with drift.
> Support DECADE time unit in EXTRACT function
>
>
> Key: CALCITE-2303
> URL: https://issues.apache.org/jira/browse/CALCITE-2303
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Sergey Nuyanzin
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> Here CALCITE-1177 were supported new units
> however such test
> {code:java}
> @Test public void testDecadeFunction() throws Exception {
> ExpressionChecker checker = new ExpressionChecker()
> .addExpr("EXTRACT(DECADE FROM ts)", 199L)
> ;
> checker.buildRunAndCheck();
> }
> {code}
> failed like
> Extract for time unit: DECADE not supported!
> {noformat}
> SQL:>
> SELECT EXTRACT(DECADE FROM ts) FROM PCOLLECTION
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> validateAndConvert
> INFO: SQL:
> SELECT EXTRACT(DECADE FROM `PCOLLECTION`.`ts`)
> FROM `PCOLLECTION` AS `PCOLLECTION`
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> convertToBeamRel
> INFO: SQLPlan>
> LogicalProject(EXPR$0=[EXTRACT(FLAG(DECADE), $0)])
> BeamIOSourceRel(table=[[PCOLLECTION]])
> java.lang.RuntimeException:
> org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
> supported!
> at
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlBuiltinFunctionsIntegrationTestBase$ExpressionChecker.buildRunAndCheck(BeamSqlBuiltinFunctionsIntegrationTestBase.java:167)
> at
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlDateFunctionsIntegrationTest.testDecadeFunction(BeamSqlDateFunctionsIntegrationTest.java:66)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.beam.sdk.testing.TestPipeline$1.evaluate(TestPipeline.java:317)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
> supported!
> at
> org.apache.beam.runners.direct.DirectRunner$DirectPipelineResult.waitUntilFinish(DirectRunner.java:349)
> at
> org.apache.beam.runners.direct.DirectRunner$DirectPipelineResult.waitUntilFinish(DirectRunner.java:319)
> at
>
[jira] [Commented] (CALCITE-2339) JDBC adapter should transform timestamp arithmetic for target database
[
https://issues.apache.org/jira/browse/CALCITE-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495921#comment-16495921
]
Laurent Goujon commented on CALCITE-2339:
-
{quote}
Laurent Goujon, That would be quite a significant change, because DATETIME_PLUS
only takes two arguments: a timestamp and an interval. And WEEK is not a
supported unit of interval types. Are you proposing to add an extra parameter?
{quote}
Not an extra argument, but it looks like {{IntervalSqlType}} operand is derived
from {{SqlIntervalQualifier}}, and that {{WEEK}} is could a possible interval
qualifier (it looks like that {{SqlIntervalQualifier#typeName()}} returns more
than just SQL intervals). So even if {{WEEK}} is not a valid interval type from
a parsing/validation point of view, any drawback of creating a call with a
{{WEEK}} {{IntervalSqlType}} operand in the convertlet?
> JDBC adapter should transform timestamp arithmetic for target database
> ---
>
> Key: CALCITE-2339
> URL: https://issues.apache.org/jira/browse/CALCITE-2339
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Attachments: Datetime Addition - Calcite.pdf
>
>
> JDBC adapter should transform timestamp arithmetic for target database.
> There are two ways in Calcite to add intervals to timestamps: the
> TIMESTAMP_ADD function and the " + " operator.
> The attached document (authored by James Doung) describes their pros and cons.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2339) JDBC adapter should transform timestamp arithmetic for target database
[
https://issues.apache.org/jira/browse/CALCITE-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495921#comment-16495921
]
Laurent Goujon edited comment on CALCITE-2339 at 5/31/18 12:15 AM:
---
{quote}
Laurent Goujon, That would be quite a significant change, because DATETIME_PLUS
only takes two arguments: a timestamp and an interval. And WEEK is not a
supported unit of interval types. Are you proposing to add an extra parameter?
{quote}
Not an extra argument, but it looks like {{IntervalSqlType}} operand is derived
from {{SqlIntervalQualifier}}, and that {{WEEK}} could be a possible interval
qualifier (it looks like that {{SqlIntervalQualifier#typeName()}} returns more
than just SQL intervals). So even if {{WEEK}} is not a valid interval type from
a parsing/validation point of view, any drawback of creating a call with a
{{WEEK}} {{IntervalSqlType}} operand in the convertlet?
was (Author: laurentgo):
{quote}
Laurent Goujon, That would be quite a significant change, because DATETIME_PLUS
only takes two arguments: a timestamp and an interval. And WEEK is not a
supported unit of interval types. Are you proposing to add an extra parameter?
{quote}
Not an extra argument, but it looks like {{IntervalSqlType}} operand is derived
from {{SqlIntervalQualifier}}, and that {{WEEK}} is could a possible interval
qualifier (it looks like that {{SqlIntervalQualifier#typeName()}} returns more
than just SQL intervals). So even if {{WEEK}} is not a valid interval type from
a parsing/validation point of view, any drawback of creating a call with a
{{WEEK}} {{IntervalSqlType}} operand in the convertlet?
> JDBC adapter should transform timestamp arithmetic for target database
> ---
>
> Key: CALCITE-2339
> URL: https://issues.apache.org/jira/browse/CALCITE-2339
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Attachments: Datetime Addition - Calcite.pdf
>
>
> JDBC adapter should transform timestamp arithmetic for target database.
> There are two ways in Calcite to add intervals to timestamps: the
> TIMESTAMP_ADD function and the " + " operator.
> The attached document (authored by James Doung) describes their pros and cons.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2303) Support DECADE time unit in EXTRACT function
[
https://issues.apache.org/jira/browse/CALCITE-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495909#comment-16495909
]
Laurent Goujon commented on CALCITE-2303:
-
I'm still not asking for a bug compatibility mode:
- first, you say bug, I say following different standard (and maybe there would
be benefit for the community to choose which standard to follow?)
- second, I don't want a flag in Calcite to turn on/off some specific
behaviours (especially this one), and Calcite project maintaining that flag
indefinitively, I am just asking if some sane/generic interface which can be
used by the Calcite library community to follow a different convention is
something which makes sense
> Support DECADE time unit in EXTRACT function
>
>
> Key: CALCITE-2303
> URL: https://issues.apache.org/jira/browse/CALCITE-2303
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Sergey Nuyanzin
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> Here CALCITE-1177 were supported new units
> however such test
> {code:java}
> @Test public void testDecadeFunction() throws Exception {
> ExpressionChecker checker = new ExpressionChecker()
> .addExpr("EXTRACT(DECADE FROM ts)", 199L)
> ;
> checker.buildRunAndCheck();
> }
> {code}
> failed like
> Extract for time unit: DECADE not supported!
> {noformat}
> SQL:>
> SELECT EXTRACT(DECADE FROM ts) FROM PCOLLECTION
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> validateAndConvert
> INFO: SQL:
> SELECT EXTRACT(DECADE FROM `PCOLLECTION`.`ts`)
> FROM `PCOLLECTION` AS `PCOLLECTION`
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> convertToBeamRel
> INFO: SQLPlan>
> LogicalProject(EXPR$0=[EXTRACT(FLAG(DECADE), $0)])
> BeamIOSourceRel(table=[[PCOLLECTION]])
> java.lang.RuntimeException:
> org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
> supported!
> at
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlBuiltinFunctionsIntegrationTestBase$ExpressionChecker.buildRunAndCheck(BeamSqlBuiltinFunctionsIntegrationTestBase.java:167)
> at
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlDateFunctionsIntegrationTest.testDecadeFunction(BeamSqlDateFunctionsIntegrationTest.java:66)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.beam.sdk.testing.TestPipeline$1.evaluate(TestPipeline.java:317)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
> supported!
> at
> org.apache.beam.runners.direct.DirectRunner$DirectPipelineResult.waitUntilFinish(DirectRunner.java:349)
> at
>
[jira] [Commented] (CALCITE-2339) JDBC adapter should transform timestamp arithmetic for target database
[ https://issues.apache.org/jira/browse/CALCITE-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495902#comment-16495902 ] James Duong commented on CALCITE-2339: -- Tableau does make use of non-interval units such as WEEK and QUARTER. > JDBC adapter should transform timestamp arithmetic for target database > --- > > Key: CALCITE-2339 > URL: https://issues.apache.org/jira/browse/CALCITE-2339 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Attachments: Datetime Addition - Calcite.pdf > > > JDBC adapter should transform timestamp arithmetic for target database. > There are two ways in Calcite to add intervals to timestamps: the > TIMESTAMP_ADD function and the " + " operator. > The attached document (authored by James Doung) describes their pros and cons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2303) Support DECADE time unit in EXTRACT function
[
https://issues.apache.org/jira/browse/CALCITE-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495900#comment-16495900
]
Julian Hyde commented on CALCITE-2303:
--
As a committer, you have to figure out whether a feature benefits the community
as a whole. A bug-compatibility mode would benefit Dremio a lot but harm
everyone else a little (due to complexity) and harm future maintainers quite a
lot (due to having to maintain compatibility).
> Support DECADE time unit in EXTRACT function
>
>
> Key: CALCITE-2303
> URL: https://issues.apache.org/jira/browse/CALCITE-2303
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Sergey Nuyanzin
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> Here CALCITE-1177 were supported new units
> however such test
> {code:java}
> @Test public void testDecadeFunction() throws Exception {
> ExpressionChecker checker = new ExpressionChecker()
> .addExpr("EXTRACT(DECADE FROM ts)", 199L)
> ;
> checker.buildRunAndCheck();
> }
> {code}
> failed like
> Extract for time unit: DECADE not supported!
> {noformat}
> SQL:>
> SELECT EXTRACT(DECADE FROM ts) FROM PCOLLECTION
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> validateAndConvert
> INFO: SQL:
> SELECT EXTRACT(DECADE FROM `PCOLLECTION`.`ts`)
> FROM `PCOLLECTION` AS `PCOLLECTION`
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> convertToBeamRel
> INFO: SQLPlan>
> LogicalProject(EXPR$0=[EXTRACT(FLAG(DECADE), $0)])
> BeamIOSourceRel(table=[[PCOLLECTION]])
> java.lang.RuntimeException:
> org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
> supported!
> at
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlBuiltinFunctionsIntegrationTestBase$ExpressionChecker.buildRunAndCheck(BeamSqlBuiltinFunctionsIntegrationTestBase.java:167)
> at
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlDateFunctionsIntegrationTest.testDecadeFunction(BeamSqlDateFunctionsIntegrationTest.java:66)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.beam.sdk.testing.TestPipeline$1.evaluate(TestPipeline.java:317)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
> supported!
> at
> org.apache.beam.runners.direct.DirectRunner$DirectPipelineResult.waitUntilFinish(DirectRunner.java:349)
> at
> org.apache.beam.runners.direct.DirectRunner$DirectPipelineResult.waitUntilFinish(DirectRunner.java:319)
> at
> org.apache.beam.runners.direct.DirectRunner.run(DirectRunner.java:210)
> at
[jira] [Commented] (CALCITE-2303) Support DECADE time unit in EXTRACT function
[
https://issues.apache.org/jira/browse/CALCITE-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495898#comment-16495898
]
Julian Hyde commented on CALCITE-2303:
--
We tend to shadow Postgres because Postgres has made some sane extensions. If,
for example, Postgres is the only DB that supports EXTRACT(DOW) then there's no
conflict if we go with Postgres.
If you are in, say, Oracle compatibility mode we won't make a huge effort to
disallow features that occur in Postgres but not Oracle.
Happy to draw features from other databases as long as they are sane. (Using
INTEGER as if it were a boolean - a MySQL extension - is not sane IMHO.)
> Support DECADE time unit in EXTRACT function
>
>
> Key: CALCITE-2303
> URL: https://issues.apache.org/jira/browse/CALCITE-2303
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Sergey Nuyanzin
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> Here CALCITE-1177 were supported new units
> however such test
> {code:java}
> @Test public void testDecadeFunction() throws Exception {
> ExpressionChecker checker = new ExpressionChecker()
> .addExpr("EXTRACT(DECADE FROM ts)", 199L)
> ;
> checker.buildRunAndCheck();
> }
> {code}
> failed like
> Extract for time unit: DECADE not supported!
> {noformat}
> SQL:>
> SELECT EXTRACT(DECADE FROM ts) FROM PCOLLECTION
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> validateAndConvert
> INFO: SQL:
> SELECT EXTRACT(DECADE FROM `PCOLLECTION`.`ts`)
> FROM `PCOLLECTION` AS `PCOLLECTION`
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> convertToBeamRel
> INFO: SQLPlan>
> LogicalProject(EXPR$0=[EXTRACT(FLAG(DECADE), $0)])
> BeamIOSourceRel(table=[[PCOLLECTION]])
> java.lang.RuntimeException:
> org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
> supported!
> at
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlBuiltinFunctionsIntegrationTestBase$ExpressionChecker.buildRunAndCheck(BeamSqlBuiltinFunctionsIntegrationTestBase.java:167)
> at
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlDateFunctionsIntegrationTest.testDecadeFunction(BeamSqlDateFunctionsIntegrationTest.java:66)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.beam.sdk.testing.TestPipeline$1.evaluate(TestPipeline.java:317)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
> supported!
> at
> org.apache.beam.runners.direct.DirectRunner$DirectPipelineResult.waitUntilFinish(DirectRunner.java:349)
> at
>
[jira] [Commented] (CALCITE-2330) Release Avatica 1.12
[ https://issues.apache.org/jira/browse/CALCITE-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495897#comment-16495897 ] Francis Chuang commented on CALCITE-2330: - That makes sense! I'll use the same approach for this release. > Release Avatica 1.12 > > > Key: CALCITE-2330 > URL: https://issues.apache.org/jira/browse/CALCITE-2330 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Francis Chuang >Priority: Major > Fix For: avatica-1.12.0 > > > Release Avatica 1.12. > We are targeting the second week of June for release; last release (1.11) was > March 2018 and the one before (1.10) that was May 2017. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2330) Release Avatica 1.12
[ https://issues.apache.org/jira/browse/CALCITE-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495895#comment-16495895 ] Julian Hyde commented on CALCITE-2330: -- My personal preference is to close master from the start of the vote until the end (success or fail). Then the release will be a commit on the main code line. Other folks aren't totally comfortable with this. If we were a project with multiple commits per day and multiple maintenance branches then I would agree with them, but at the current dev rates I don't think it's too much of a hardship for people to hold back their commits for a few days. > Release Avatica 1.12 > > > Key: CALCITE-2330 > URL: https://issues.apache.org/jira/browse/CALCITE-2330 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Francis Chuang >Priority: Major > Fix For: avatica-1.12.0 > > > Release Avatica 1.12. > We are targeting the second week of June for release; last release (1.11) was > March 2018 and the one before (1.10) that was May 2017. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2330) Release Avatica 1.12
[ https://issues.apache.org/jira/browse/CALCITE-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495890#comment-16495890 ] Francis Chuang commented on CALCITE-2330: - [~julianhyde] Thanks, that makes a lot of sense. Is there some guideline for when master should be declared closed? I am assuming once we get all the PRs and changes we want for this release in, we close master. > Release Avatica 1.12 > > > Key: CALCITE-2330 > URL: https://issues.apache.org/jira/browse/CALCITE-2330 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Francis Chuang >Priority: Major > Fix For: avatica-1.12.0 > > > Release Avatica 1.12. > We are targeting the second week of June for release; last release (1.11) was > March 2018 and the one before (1.10) that was May 2017. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2303) Support DECADE time unit in EXTRACT function
[
https://issues.apache.org/jira/browse/CALCITE-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495889#comment-16495889
]
Laurent Goujon commented on CALCITE-2303:
-
(Note that behaviour change in Dremio at some point to match ODBC spec across
the board as it seems to be what most tools expect)
> Support DECADE time unit in EXTRACT function
>
>
> Key: CALCITE-2303
> URL: https://issues.apache.org/jira/browse/CALCITE-2303
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Sergey Nuyanzin
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> Here CALCITE-1177 were supported new units
> however such test
> {code:java}
> @Test public void testDecadeFunction() throws Exception {
> ExpressionChecker checker = new ExpressionChecker()
> .addExpr("EXTRACT(DECADE FROM ts)", 199L)
> ;
> checker.buildRunAndCheck();
> }
> {code}
> failed like
> Extract for time unit: DECADE not supported!
> {noformat}
> SQL:>
> SELECT EXTRACT(DECADE FROM ts) FROM PCOLLECTION
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> validateAndConvert
> INFO: SQL:
> SELECT EXTRACT(DECADE FROM `PCOLLECTION`.`ts`)
> FROM `PCOLLECTION` AS `PCOLLECTION`
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> convertToBeamRel
> INFO: SQLPlan>
> LogicalProject(EXPR$0=[EXTRACT(FLAG(DECADE), $0)])
> BeamIOSourceRel(table=[[PCOLLECTION]])
> java.lang.RuntimeException:
> org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
> supported!
> at
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlBuiltinFunctionsIntegrationTestBase$ExpressionChecker.buildRunAndCheck(BeamSqlBuiltinFunctionsIntegrationTestBase.java:167)
> at
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlDateFunctionsIntegrationTest.testDecadeFunction(BeamSqlDateFunctionsIntegrationTest.java:66)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.beam.sdk.testing.TestPipeline$1.evaluate(TestPipeline.java:317)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
> supported!
> at
> org.apache.beam.runners.direct.DirectRunner$DirectPipelineResult.waitUntilFinish(DirectRunner.java:349)
> at
> org.apache.beam.runners.direct.DirectRunner$DirectPipelineResult.waitUntilFinish(DirectRunner.java:319)
> at
> org.apache.beam.runners.direct.DirectRunner.run(DirectRunner.java:210)
> at org.apache.beam.runners.direct.DirectRunner.run(DirectRunner.java:66)
> at org.apache.beam.sdk.Pipeline.run(Pipeline.java:311)
> at org.apache.beam.sdk.testing.TestPipeline.run(TestPipeline.java:346)
[jira] [Comment Edited] (CALCITE-2303) Support DECADE time unit in EXTRACT function
[
https://issues.apache.org/jira/browse/CALCITE-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495886#comment-16495886
]
Laurent Goujon edited comment on CALCITE-2303 at 5/30/18 11:42 PM:
---
I'm not suggesting a bug-compatibility mode, but at least a provision for a
Calcite user (as in library user, but not necessarily end-user) to alter
operands behaviour to match its needs. It's not a area of Calcite I know well
for sure, but my impression is that the core of the implementation is around
RexImpTable which is basically a singleton.
Also, is Calcite always shadowing Postgres behaviour, which is considered the
reference behavior?
as for the behavior regarding DOW across database, sharing an internal analysis
we did too:
||System||Syntax||Sun||Mon||Tues||Wed||Thurs||Fri||Sat||Comments||
|Dremio (old)|DAYOFWEEK()|7|1|2|3|4|5|6|...|
|Dremio (old)|EXTRACT(DOW FROM )|7|1|2|3|4|5|6|...|
|Dremio (old)|DATE_PART('DOW', )|7|1|2|3|4|5|6|...|
|Dremio (old)|TO_CHAR(, 'd')|7|1|2|3|4|5|6|...|
|Dremio (new)|DAYOFWEEK()|1|2|3|4|5|6|7|...|
|Dremio (new)|EXTRACT(DOW FROM )|1|2|3|4|5|6|7|...|
|Dremio (new)|DATE_PART('DOW', )|1|2|3|4|5|6|7|...|
|Dremio (new)|TO_CHAR(, 'd')|1|2|3|4|5|6|7|...|
|Oracle (USA)|TO_CHAR(DATE , 'd')|1|2|3|4|5|6|7|Depends on NLS_TERRITORY:
[https://tonyhasler.wordpress.com/2010/01/16/232/]|
|PostgreSQL|TO_CHAR(DATE , 'd')|1|2|3|4|5|6|7|...|
|SQL Server|DATEPART(DW, )|1|2|3|4|5|6|7|Customizable (US vs non US):
[http://www.itprotoday.com/software-development/datefirst-and-datepart-relationship]|
|MySQL|DAYOFWEEK()|1|2|3|4|5|6|7|[https://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_dayofweek]|
|Oracle (UK)|TO_CHAR(DATE , 'd')|7|1|2|3|4|5|6|Depends on NLS_TERRITORY:
[https://tonyhasler.wordpress.com/2010/01/16/232/]|
|PostgreSQL|EXTRACT(ISODOW FROM DATE
)|7|1|2|3|4|5|6|[https://stackoverflow.com/questions/41181990/extract-day-of-week-from-date-field-in-postgresql-assuming-weeks-start-on-monday]|
|PostgreSQL|EXTRACT(DOW FROM DATE
)|0|1|2|3|4|5|6|[https://www.postgresql.org/docs/8.1/static/functions-datetime.html#FUNCTIONS-DATETIME-EXTRACT]|
|PostgreSQL|DATE_PART('DOW', DATE
)|0|1|2|3|4|5|6|[https://www.postgresql.org/docs/8.1/static/functions-datetime.html#FUNCTIONS-DATETIME-EXTRACT]|
|MySQL|WEEKDAY()|6|0|1|2|3|4|5|[https://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_week]|
|DB2|EXTRACT(DOW FROM
)|1|2|3|4|5|6|7|[https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.sql.ref.doc/doc/r0053629.html]|
|DB2|DAYOFWEEK([, ])|1|2|3|4|5|6|7|default for startofweek
is 1 (sunday)
[https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.sql.ref.doc/doc/r787.html]|
|BigQuery|EXTRACT(DAYOFWEEK FROM
)|1|2|3|4|5|6|7|[https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#extract]|
|PrestoDB|EXTRACT(DAY_OF_WEEK\|DOW FROM
)|1|2|3|4|5|6|7|[https://prestodb.io/docs/current/functions/datetime.html#day_of_week]|
|Hive|EXTRACT(DAYOFWEEK FROM
)|1|2|3|4|5|6|7|[https://cwiki.apache.org/confluence/display/Hive/LanguageManual+UDF#LanguageManualUDF-DateFunctions]|
|Vertica|EXTRACT(DOW FROM
)|0|1|2|3|4|5|6|[https://my.vertica.com/docs/9.1.x/HTML/index.htm#Authoring/SQLReferenceManual/Functions/Date-Time/EXTRACT.htm?Highlight=extract]|
|Vertica|DATE_PART('DOW',
)|0|1|2|3|4|5|6|[https://my.vertica.com/docs/9.1.x/HTML/index.htm#Authoring/SQLReferenceManual/Functions/Date-Time/DATE_PART.htm?Highlight=extract]|
|Vertica|TO_CHAR(,
'D')|7|1|2|3|4|5|6|https://my.vertica.com/docs/9.1.x/HTML/index.htm#Authoring/SQLReferenceManual/Functions/Formatting/TO_CHAR.htm?Highlight=extract|
was (Author: laurentgo):
I'm not suggesting a bug-compatibility mode, but at least a provision for a
Calcite user (as in library user, but not necessarily end-user) to alter
operands behaviour to match its needs. It's not a area of Calcite I know well
for sure, but my impression is that the core of the implementation is around
RexImpTable which is basically a singleton.
Also, is Calcite always shadowing Postgres behaviour, which is considered the
reference behavior?
as for the behavior regarding DOW across database, sharing an internal analysis
we did too:
||System||Syntax||Sun||Mon||Tues||Wed||Thurs||Fri||Sat||Comments||
|Dremio|DAYOFWEEK()|7|1|2|3|4|5|6|...|
|Dremio|EXTRACT(DOW FROM )|7|1|2|3|4|5|6|...|
|Dremio|DATE_PART('DOW', )|7|1|2|3|4|5|6|...|
|Dremio|TO_CHAR(, 'd')|7|1|2|3|4|5|6|...|
|Oracle (USA)|TO_CHAR(DATE , 'd')|1|2|3|4|5|6|7|Depends on NLS_TERRITORY:
https://tonyhasler.wordpress.com/2010/01/16/232/|
|PostgreSQL|TO_CHAR(DATE , 'd')|1|2|3|4|5|6|7|...|
|SQL Server|DATEPART(DW, )|1|2|3|4|5|6|7|Customizable (US vs non US):
http://www.itprotoday.com/software-development/datefirst-and-datepart-relationship|
|MySQL|DAYOFWEEK()|1|2|3|4|5|6|7|
[jira] [Commented] (CALCITE-2339) JDBC adapter should transform timestamp arithmetic for target database
[ https://issues.apache.org/jira/browse/CALCITE-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495888#comment-16495888 ] Julian Hyde commented on CALCITE-2339: -- My point about WEEK is that 99.2% (I'm guessing) of intervals in real-world SQL are one of the core interval types. So WEEK is not really worth worrying about. > JDBC adapter should transform timestamp arithmetic for target database > --- > > Key: CALCITE-2339 > URL: https://issues.apache.org/jira/browse/CALCITE-2339 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Attachments: Datetime Addition - Calcite.pdf > > > JDBC adapter should transform timestamp arithmetic for target database. > There are two ways in Calcite to add intervals to timestamps: the > TIMESTAMP_ADD function and the " + " operator. > The attached document (authored by James Doung) describes their pros and cons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2303) Support DECADE time unit in EXTRACT function
[
https://issues.apache.org/jira/browse/CALCITE-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495886#comment-16495886
]
Laurent Goujon commented on CALCITE-2303:
-
I'm not suggesting a bug-compatibility mode, but at least a provision for a
Calcite user (as in library user, but not necessarily end-user) to alter
operands behaviour to match its needs. It's not a area of Calcite I know well
for sure, but my impression is that the core of the implementation is around
RexImpTable which is basically a singleton.
Also, is Calcite always shadowing Postgres behaviour, which is considered the
reference behavior?
as for the behavior regarding DOW across database, sharing an internal analysis
we did too:
||System||Syntax||Sun||Mon||Tues||Wed||Thurs||Fri||Sat||Comments||
|Dremio|DAYOFWEEK()|7|1|2|3|4|5|6|...|
|Dremio|EXTRACT(DOW FROM )|7|1|2|3|4|5|6|...|
|Dremio|DATE_PART('DOW', )|7|1|2|3|4|5|6|...|
|Dremio|TO_CHAR(, 'd')|7|1|2|3|4|5|6|...|
|Oracle (USA)|TO_CHAR(DATE , 'd')|1|2|3|4|5|6|7|Depends on NLS_TERRITORY:
https://tonyhasler.wordpress.com/2010/01/16/232/|
|PostgreSQL|TO_CHAR(DATE , 'd')|1|2|3|4|5|6|7|...|
|SQL Server|DATEPART(DW, )|1|2|3|4|5|6|7|Customizable (US vs non US):
http://www.itprotoday.com/software-development/datefirst-and-datepart-relationship|
|MySQL|DAYOFWEEK()|1|2|3|4|5|6|7|
https://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_dayofweek|
|Oracle (UK)|TO_CHAR(DATE , 'd')|7|1|2|3|4|5|6|Depends on NLS_TERRITORY:
https://tonyhasler.wordpress.com/2010/01/16/232/|
|PostgreSQL|EXTRACT(ISODOW FROM DATE )|7|1|2|3|4|5|6|
https://stackoverflow.com/questions/41181990/extract-day-of-week-from-date-field-in-postgresql-assuming-weeks-start-on-monday|
|PostgreSQL|EXTRACT(DOW FROM DATE )|0|1|2|3|4|5|6|
https://www.postgresql.org/docs/8.1/static/functions-datetime.html#FUNCTIONS-DATETIME-EXTRACT|
|PostgreSQL|DATE_PART('DOW', DATE )|0|1|2|3|4|5|6|
https://www.postgresql.org/docs/8.1/static/functions-datetime.html#FUNCTIONS-DATETIME-EXTRACT|
|MySQL|WEEKDAY()|6|0|1|2|3|4|5|
https://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_week|
|DB2|EXTRACT(DOW FROM )|1|2|3|4|5|6|7|
https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.sql.ref.doc/doc/r0053629.html|
|DB2|DAYOFWEEK(\[, \])|1|2|3|4|5|6|7| default for
startofweek is 1 (sunday)
https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.sql.ref.doc/doc/r787.html|
|BigQuery|EXTRACT(DAYOFWEEK FROM )|1|2|3|4|5|6|7|
https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#extract|
|PrestoDB|EXTRACT(DAY_OF_WEEK\|DOW FROM )|1|2|3|4|5|6|7|
https://prestodb.io/docs/current/functions/datetime.html#day_of_week|
|Hive|EXTRACT(DAYOFWEEK FROM )|1|2|3|4|5|6|7|
https://cwiki.apache.org/confluence/display/Hive/LanguageManual+UDF#LanguageManualUDF-DateFunctions|
|Vertica|EXTRACT(DOW FROM )|0|1|2|3|4|5|6|
https://my.vertica.com/docs/9.1.x/HTML/index.htm#Authoring/SQLReferenceManual/Functions/Date-Time/EXTRACT.htm?Highlight=extract|
|Vertica|DATE_PART('DOW', )|0|1|2|3|4|5|6|
https://my.vertica.com/docs/9.1.x/HTML/index.htm#Authoring/SQLReferenceManual/Functions/Date-Time/DATE_PART.htm?Highlight=extract|
|Vertica|TO_CHAR(,
'D')|7|1|2|3|4|5|6|https://my.vertica.com/docs/9.1.x/HTML/index.htm#Authoring/SQLReferenceManual/Functions/Formatting/TO_CHAR.htm?Highlight=extract|
> Support DECADE time unit in EXTRACT function
>
>
> Key: CALCITE-2303
> URL: https://issues.apache.org/jira/browse/CALCITE-2303
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Sergey Nuyanzin
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> Here CALCITE-1177 were supported new units
> however such test
> {code:java}
> @Test public void testDecadeFunction() throws Exception {
> ExpressionChecker checker = new ExpressionChecker()
> .addExpr("EXTRACT(DECADE FROM ts)", 199L)
> ;
> checker.buildRunAndCheck();
> }
> {code}
> failed like
> Extract for time unit: DECADE not supported!
> {noformat}
> SQL:>
> SELECT EXTRACT(DECADE FROM ts) FROM PCOLLECTION
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> validateAndConvert
> INFO: SQL:
> SELECT EXTRACT(DECADE FROM `PCOLLECTION`.`ts`)
> FROM `PCOLLECTION` AS `PCOLLECTION`
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> convertToBeamRel
> INFO: SQLPlan>
> LogicalProject(EXPR$0=[EXTRACT(FLAG(DECADE), $0)])
> BeamIOSourceRel(table=[[PCOLLECTION]])
> java.lang.RuntimeException:
> org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
> supported!
> at
[jira] [Commented] (CALCITE-2294) Allow customization for AvaticaServerConfiguration for plugging new authentication mechanisms
[
https://issues.apache.org/jira/browse/CALCITE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495887#comment-16495887
]
Karan Mehta commented on CALCITE-2294:
--
Thanks [~elserj] for quick turn around! Looking forward to working with you as
well!
> Allow customization for AvaticaServerConfiguration for plugging new
> authentication mechanisms
> -
>
> Key: CALCITE-2294
> URL: https://issues.apache.org/jira/browse/CALCITE-2294
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Fix For: avatica-1.12.0
>
>
> {{AvaticaServerConfiguration}} is currently only created if authentication
> mechanism such as {{BASIC, DIGEST or SPNEGO}} is provided. We can change it
> to a builder pattern to create this object and provide a way for users to
> plugin their own security configuration.
> An example here can be using it for custom config that supports MTLS.
> Thanks [~alexaraujo] for suggesting this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2339) JDBC adapter should transform timestamp arithmetic for target database
[
https://issues.apache.org/jira/browse/CALCITE-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495885#comment-16495885
]
Julian Hyde commented on CALCITE-2339:
--
[~laurentgo], That would be quite a significant change, because DATETIME_PLUS
only takes two arguments: a timestamp and an interval. And WEEK is not a
supported unit of interval types. Are you proposing to add an extra parameter?
[~jduong], You could simplify {{integer_column * 1}} to {{integer_column}}.
> JDBC adapter should transform timestamp arithmetic for target database
> ---
>
> Key: CALCITE-2339
> URL: https://issues.apache.org/jira/browse/CALCITE-2339
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Attachments: Datetime Addition - Calcite.pdf
>
>
> JDBC adapter should transform timestamp arithmetic for target database.
> There are two ways in Calcite to add intervals to timestamps: the
> TIMESTAMP_ADD function and the " + " operator.
> The attached document (authored by James Doung) describes their pros and cons.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2330) Release Avatica 1.12
[ https://issues.apache.org/jira/browse/CALCITE-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495884#comment-16495884 ] Julian Hyde commented on CALCITE-2330: -- [~francischuang], May I suggest a different strategy. As RM you own branch-avatica-1.12 and only you should merge or push to it. For now the repository is "open" for commits, and committers will merge to the master branch. But at some point you can declare the repository "closed". Force-pushing to master is discouraged, but you are welcome to force-push to branch-avatica-1.12 (as you are the only person using it). You should probably rebase the release branch onto master periodically, until you declare master closed. In the release branch you can start writing release notes, update version numbers in documentation, and so forth. > Release Avatica 1.12 > > > Key: CALCITE-2330 > URL: https://issues.apache.org/jira/browse/CALCITE-2330 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Francis Chuang >Priority: Major > Fix For: avatica-1.12.0 > > > Release Avatica 1.12. > We are targeting the second week of June for release; last release (1.11) was > March 2018 and the one before (1.10) that was May 2017. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2330) Release Avatica 1.12
[ https://issues.apache.org/jira/browse/CALCITE-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495879#comment-16495879 ] Francis Chuang edited comment on CALCITE-2330 at 5/30/18 11:33 PM: --- [~elserj], Thanks! Let's do all our work on branch-avatica-1.12 from now onwards (until release). Edit: Just saw that it's merged to master. I'll pull the changes into the release branch. Thanks [~karanmehta93]! was (Author: francischuang): [~elserj], Thanks! Let's do all our work on branch-avatica-1.12 from now onwards (until release). Edit: Just saw that it's merged to master. I'll pull the changes into the release branch. > Release Avatica 1.12 > > > Key: CALCITE-2330 > URL: https://issues.apache.org/jira/browse/CALCITE-2330 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Francis Chuang >Priority: Major > Fix For: avatica-1.12.0 > > > Release Avatica 1.12. > We are targeting the second week of June for release; last release (1.11) was > March 2018 and the one before (1.10) that was May 2017. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2330) Release Avatica 1.12
[ https://issues.apache.org/jira/browse/CALCITE-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495879#comment-16495879 ] Francis Chuang commented on CALCITE-2330: - [~elserj], Thanks! Let's do all our work on branch-avatica-1.12 from now onwards. > Release Avatica 1.12 > > > Key: CALCITE-2330 > URL: https://issues.apache.org/jira/browse/CALCITE-2330 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Francis Chuang >Priority: Major > Fix For: avatica-1.12.0 > > > Release Avatica 1.12. > We are targeting the second week of June for release; last release (1.11) was > March 2018 and the one before (1.10) that was May 2017. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2339) JDBC adapter should transform timestamp arithmetic for target database
[
https://issues.apache.org/jira/browse/CALCITE-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495873#comment-16495873
]
Laurent Goujon commented on CALCITE-2339:
-
Could we change the {{DATETIME_PLUS}} operator to support non-standard/internal
interval types so that WEEK can be represented as such and being preserved up
to each adapter?
> JDBC adapter should transform timestamp arithmetic for target database
> ---
>
> Key: CALCITE-2339
> URL: https://issues.apache.org/jira/browse/CALCITE-2339
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Attachments: Datetime Addition - Calcite.pdf
>
>
> JDBC adapter should transform timestamp arithmetic for target database.
> There are two ways in Calcite to add intervals to timestamps: the
> TIMESTAMP_ADD function and the " + " operator.
> The attached document (authored by James Doung) describes their pros and cons.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2339) JDBC adapter should transform timestamp arithmetic for target database
[ https://issues.apache.org/jira/browse/CALCITE-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495869#comment-16495869 ] James Duong edited comment on CALCITE-2339 at 5/30/18 11:17 PM: The other downside I see: If someone used TIMESTAMPADD(ts, integer_column, DAY), we'd have to transform this to ts + integer_column * Interval '1' DAY, then transform it back to TIMESTAMPADD(ts, integer_column * 1, DAY) was (Author: jduong): The other downside I see: If someone used TIMESTAMPADD(ts, integer_column, DAY), we'd have to transform this to ts + integer_column * Interval '1' DAY, then transform it back to TIMESTAMPADD(ts, integer_column * 1, DAY) or if the interval's a non-literal: TIMESTAMPADD(ts, integer_column * cast(interval_expression as integer), DAY) > JDBC adapter should transform timestamp arithmetic for target database > --- > > Key: CALCITE-2339 > URL: https://issues.apache.org/jira/browse/CALCITE-2339 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Attachments: Datetime Addition - Calcite.pdf > > > JDBC adapter should transform timestamp arithmetic for target database. > There are two ways in Calcite to add intervals to timestamps: the > TIMESTAMP_ADD function and the " + " operator. > The attached document (authored by James Doung) describes their pros and cons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2339) JDBC adapter should transform timestamp arithmetic for target database
[ https://issues.apache.org/jira/browse/CALCITE-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495869#comment-16495869 ] James Duong commented on CALCITE-2339: -- The other downside I see: If someone used TIMESTAMPADD(ts, integer_column, DAY), we'd have to transform this to ts + integer_column * Interval '1' DAY, then transform it back to TIMESTAMPADD(ts, integer_column * 1, DAY) or if the interval's a non-literal: TIMESTAMPADD(ts, integer_column * cast(interval_expression as integer), DAY) > JDBC adapter should transform timestamp arithmetic for target database > --- > > Key: CALCITE-2339 > URL: https://issues.apache.org/jira/browse/CALCITE-2339 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Attachments: Datetime Addition - Calcite.pdf > > > JDBC adapter should transform timestamp arithmetic for target database. > There are two ways in Calcite to add intervals to timestamps: the > TIMESTAMP_ADD function and the " + " operator. > The attached document (authored by James Doung) describes their pros and cons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2303) Support DECADE time unit in EXTRACT function
[
https://issues.apache.org/jira/browse/CALCITE-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495862#comment-16495862
]
Julian Hyde commented on CALCITE-2303:
--
If you're suggesting adding a bug-compatibility mode... I'm against that idea
because it adds complexity. If there is clearly a "right behavior" and Dremio
is relying on Calcite's "wrong behavior" then Dremio needs to absorb the impact
of that change, not Calcite.
> Support DECADE time unit in EXTRACT function
>
>
> Key: CALCITE-2303
> URL: https://issues.apache.org/jira/browse/CALCITE-2303
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Sergey Nuyanzin
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> Here CALCITE-1177 were supported new units
> however such test
> {code:java}
> @Test public void testDecadeFunction() throws Exception {
> ExpressionChecker checker = new ExpressionChecker()
> .addExpr("EXTRACT(DECADE FROM ts)", 199L)
> ;
> checker.buildRunAndCheck();
> }
> {code}
> failed like
> Extract for time unit: DECADE not supported!
> {noformat}
> SQL:>
> SELECT EXTRACT(DECADE FROM ts) FROM PCOLLECTION
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> validateAndConvert
> INFO: SQL:
> SELECT EXTRACT(DECADE FROM `PCOLLECTION`.`ts`)
> FROM `PCOLLECTION` AS `PCOLLECTION`
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> convertToBeamRel
> INFO: SQLPlan>
> LogicalProject(EXPR$0=[EXTRACT(FLAG(DECADE), $0)])
> BeamIOSourceRel(table=[[PCOLLECTION]])
> java.lang.RuntimeException:
> org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
> supported!
> at
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlBuiltinFunctionsIntegrationTestBase$ExpressionChecker.buildRunAndCheck(BeamSqlBuiltinFunctionsIntegrationTestBase.java:167)
> at
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlDateFunctionsIntegrationTest.testDecadeFunction(BeamSqlDateFunctionsIntegrationTest.java:66)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.beam.sdk.testing.TestPipeline$1.evaluate(TestPipeline.java:317)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
> supported!
> at
> org.apache.beam.runners.direct.DirectRunner$DirectPipelineResult.waitUntilFinish(DirectRunner.java:349)
> at
> org.apache.beam.runners.direct.DirectRunner$DirectPipelineResult.waitUntilFinish(DirectRunner.java:319)
> at
> org.apache.beam.runners.direct.DirectRunner.run(DirectRunner.java:210)
> at org.apache.beam.runners.direct.DirectRunner.run(DirectRunner.java:66)
> at
[jira] [Resolved] (CALCITE-2294) Allow customization for AvaticaServerConfiguration for plugging new authentication mechanisms
[
https://issues.apache.org/jira/browse/CALCITE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-2294.
-
Resolution: Fixed
Committed to master in
[https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=3ab9ec6f884607417d8e1badd69a681f958c2703]
Happy contributor status, Karan! Thanks for the work you did here. I'm truly
looking forward to working with you more :)
> Allow customization for AvaticaServerConfiguration for plugging new
> authentication mechanisms
> -
>
> Key: CALCITE-2294
> URL: https://issues.apache.org/jira/browse/CALCITE-2294
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Fix For: avatica-1.12.0
>
>
> {{AvaticaServerConfiguration}} is currently only created if authentication
> mechanism such as {{BASIC, DIGEST or SPNEGO}} is provided. We can change it
> to a builder pattern to create this object and provide a way for users to
> plugin their own security configuration.
> An example here can be using it for custom config that supports MTLS.
> Thanks [~alexaraujo] for suggesting this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CALCITE-2294) Allow customization for AvaticaServerConfiguration for plugging new authentication mechanisms
[
https://issues.apache.org/jira/browse/CALCITE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned CALCITE-2294:
---
Assignee: Karan Mehta
> Allow customization for AvaticaServerConfiguration for plugging new
> authentication mechanisms
> -
>
> Key: CALCITE-2294
> URL: https://issues.apache.org/jira/browse/CALCITE-2294
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Fix For: avatica-1.12.0
>
>
> {{AvaticaServerConfiguration}} is currently only created if authentication
> mechanism such as {{BASIC, DIGEST or SPNEGO}} is provided. We can change it
> to a builder pattern to create this object and provide a way for users to
> plugin their own security configuration.
> An example here can be using it for custom config that supports MTLS.
> Thanks [~alexaraujo] for suggesting this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2330) Release Avatica 1.12
[ https://issues.apache.org/jira/browse/CALCITE-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495854#comment-16495854 ] Josh Elser commented on CALCITE-2330: - I'm grabbing this and pulling it into master now. I'll let you grab it into the release branch if you want it, [~francischuang]. > Release Avatica 1.12 > > > Key: CALCITE-2330 > URL: https://issues.apache.org/jira/browse/CALCITE-2330 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Francis Chuang >Priority: Major > Fix For: avatica-1.12.0 > > > Release Avatica 1.12. > We are targeting the second week of June for release; last release (1.11) was > March 2018 and the one before (1.10) that was May 2017. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2294) Allow customization for AvaticaServerConfiguration for plugging new authentication mechanisms
[
https://issues.apache.org/jira/browse/CALCITE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495855#comment-16495855
]
ASF GitHub Bot commented on CALCITE-2294:
-
Github user asfgit closed the pull request at:
https://github.com/apache/calcite-avatica/pull/48
> Allow customization for AvaticaServerConfiguration for plugging new
> authentication mechanisms
> -
>
> Key: CALCITE-2294
> URL: https://issues.apache.org/jira/browse/CALCITE-2294
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Karan Mehta
>Priority: Major
> Fix For: avatica-1.12.0
>
>
> {{AvaticaServerConfiguration}} is currently only created if authentication
> mechanism such as {{BASIC, DIGEST or SPNEGO}} is provided. We can change it
> to a builder pattern to create this object and provide a way for users to
> plugin their own security configuration.
> An example here can be using it for custom config that supports MTLS.
> Thanks [~alexaraujo] for suggesting this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2303) Support DECADE time unit in EXTRACT function
[
https://issues.apache.org/jira/browse/CALCITE-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495852#comment-16495852
]
Laurent Goujon commented on CALCITE-2303:
-
Currently {{\{fn DAYOFWEEK\}}} is mapped (through {{DAYOFWEEK}}) to
{{EXTRACT(DOW FROM...}} in Calcite, so a change would be required for sure (and
haven't seen any in the Calcite patch)
That aside, there's also the problem of backward compatibility. Dremio uses
RexExecutorImpl for some expressions during constant reduction, and we want
behavior to be identical between Calcite and Dremio, and so, some of our
behavior has been modeled after Calcite behavior, but that kind of changes mean
another change, which impacts our users. I'm not sure if lots of Calcite users
are also impacted by those changes, but if behavior could be made configurable
(suggestion?), that would be a nice addition...
> Support DECADE time unit in EXTRACT function
>
>
> Key: CALCITE-2303
> URL: https://issues.apache.org/jira/browse/CALCITE-2303
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Sergey Nuyanzin
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> Here CALCITE-1177 were supported new units
> however such test
> {code:java}
> @Test public void testDecadeFunction() throws Exception {
> ExpressionChecker checker = new ExpressionChecker()
> .addExpr("EXTRACT(DECADE FROM ts)", 199L)
> ;
> checker.buildRunAndCheck();
> }
> {code}
> failed like
> Extract for time unit: DECADE not supported!
> {noformat}
> SQL:>
> SELECT EXTRACT(DECADE FROM ts) FROM PCOLLECTION
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> validateAndConvert
> INFO: SQL:
> SELECT EXTRACT(DECADE FROM `PCOLLECTION`.`ts`)
> FROM `PCOLLECTION` AS `PCOLLECTION`
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> convertToBeamRel
> INFO: SQLPlan>
> LogicalProject(EXPR$0=[EXTRACT(FLAG(DECADE), $0)])
> BeamIOSourceRel(table=[[PCOLLECTION]])
> java.lang.RuntimeException:
> org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
> supported!
> at
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlBuiltinFunctionsIntegrationTestBase$ExpressionChecker.buildRunAndCheck(BeamSqlBuiltinFunctionsIntegrationTestBase.java:167)
> at
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlDateFunctionsIntegrationTest.testDecadeFunction(BeamSqlDateFunctionsIntegrationTest.java:66)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.beam.sdk.testing.TestPipeline$1.evaluate(TestPipeline.java:317)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time
[jira] [Commented] (CALCITE-2330) Release Avatica 1.12
[ https://issues.apache.org/jira/browse/CALCITE-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495851#comment-16495851 ] Karan Mehta commented on CALCITE-2330: -- Can you also merge CALCITE-2294? The PR: [https://github.com/apache/calcite-avatica/pull/48] was reviewed by [~elserj] Thanks! > Release Avatica 1.12 > > > Key: CALCITE-2330 > URL: https://issues.apache.org/jira/browse/CALCITE-2330 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Francis Chuang >Priority: Major > Fix For: avatica-1.12.0 > > > Release Avatica 1.12. > We are targeting the second week of June for release; last release (1.11) was > March 2018 and the one before (1.10) that was May 2017. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2339) JDBC adapter should transform timestamp arithmetic for target database
[
https://issues.apache.org/jira/browse/CALCITE-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495832#comment-16495832
]
Julian Hyde edited comment on CALCITE-2339 at 5/30/18 10:51 PM:
I propose that we continue to use interval "\+" as the internal representation,
but writer a converter from an interval "\+" expression to a TIMESTAMPADD
expression that can be used by various dialects in the JDBC adapter.
The only downside I can see is that someone might write {{TIMESTAMPADD(ts, 3,
WEEK)}} and see {{TIMESTAMPADD(ts, 21, DAY)}} sent to the underlying DB. That's
not too bad. The standard intervals day, month, year, hour, second etc will
not be affected.
was (Author: julianhyde):
I propose that we continue to use interval "+" as the internal representation,
but writer a converter from an interval "+" expression to a TIMESTAMPADD
expression that can be used by various dialects in the JDBC adapter.
The only downside I can see is that someone might write {{TIMESTAMPADD(ts, 3,
WEEK)}} and see {{TIMESTAMPADD(ts, 21, DAY)}} sent to the underlying DB. That's
not too bad. The standard intervals day, month, year, hour, second etc will
not be affected.
> JDBC adapter should transform timestamp arithmetic for target database
> ---
>
> Key: CALCITE-2339
> URL: https://issues.apache.org/jira/browse/CALCITE-2339
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Attachments: Datetime Addition - Calcite.pdf
>
>
> JDBC adapter should transform timestamp arithmetic for target database.
> There are two ways in Calcite to add intervals to timestamps: the
> TIMESTAMP_ADD function and the " + " operator.
> The attached document (authored by James Doung) describes their pros and cons.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2339) JDBC adapter should transform timestamp arithmetic for target database
[
https://issues.apache.org/jira/browse/CALCITE-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495832#comment-16495832
]
Julian Hyde commented on CALCITE-2339:
--
I propose that we continue to use interval "+" as the internal representation,
but writer a converter from an interval "+" expression to a TIMESTAMPADD
expression that can be used by various dialects in the JDBC adapter.
The only downside I can see is that someone might write {{TIMESTAMPADD(ts, 3,
WEEK)}} and see {{TIMESTAMPADD(ts, 21, DAY)}} sent to the underlying DB. That's
not too bad. The standard intervals day, month, year, hour, second etc will
not be affected.
> JDBC adapter should transform timestamp arithmetic for target database
> ---
>
> Key: CALCITE-2339
> URL: https://issues.apache.org/jira/browse/CALCITE-2339
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Attachments: Datetime Addition - Calcite.pdf
>
>
> JDBC adapter should transform timestamp arithmetic for target database.
> There are two ways in Calcite to add intervals to timestamps: the
> TIMESTAMP_ADD function and the " + " operator.
> The attached document (authored by James Doung) describes their pros and cons.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2339) JDBC adapter should transform timestamp arithmetic for target database
[ https://issues.apache.org/jira/browse/CALCITE-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495824#comment-16495824 ] James Duong commented on CALCITE-2339: -- Note that it's possible to represent multi-field intervals with timestampadd. You just nest multiple timestampadd calls together for each unit. Need to apply the EXTRACT function to get individual units out of an arbitrary interval expression though. > JDBC adapter should transform timestamp arithmetic for target database > --- > > Key: CALCITE-2339 > URL: https://issues.apache.org/jira/browse/CALCITE-2339 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Attachments: Datetime Addition - Calcite.pdf > > > JDBC adapter should transform timestamp arithmetic for target database. > There are two ways in Calcite to add intervals to timestamps: the > TIMESTAMP_ADD function and the " + " operator. > The attached document (authored by James Doung) describes their pros and cons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2209) Support loading JSON model file through URL
[ https://issues.apache.org/jira/browse/CALCITE-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495823#comment-16495823 ] Shuyi Chen commented on CALCITE-2209: - Thanks a lot, Rong. Could we add a dummy protocol with a testing URLStreamHandlerFactory to verify that it works? > Support loading JSON model file through URL > --- > > Key: CALCITE-2209 > URL: https://issues.apache.org/jira/browse/CALCITE-2209 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > > Currently, Calcite only support loading JSON model file through inline or > local file. The Jira attemps to extend it to support loading JSON model file > through URL, so users can implement their own URLStreamHandlerFactory to read > the JSON model file from e.g., HDFS or etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2330) Release Avatica 1.12
[ https://issues.apache.org/jira/browse/CALCITE-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495821#comment-16495821 ] Julian Hyde commented on CALCITE-2330: -- How ironic. And, thanks! > Release Avatica 1.12 > > > Key: CALCITE-2330 > URL: https://issues.apache.org/jira/browse/CALCITE-2330 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Francis Chuang >Priority: Major > Fix For: avatica-1.12.0 > > > Release Avatica 1.12. > We are targeting the second week of June for release; last release (1.11) was > March 2018 and the one before (1.10) that was May 2017. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2330) Release Avatica 1.12
[ https://issues.apache.org/jira/browse/CALCITE-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16494567#comment-16494567 ] Julian Hyde edited comment on CALCITE-2330 at 5/30/18 10:42 PM: [~julianhyde] Fixed Calcite in [542d5126|https://git-wip-us.apache.org/repos/asf?p=calcite.git;a=commit;h=542d51265d683dfd736c5e04f556e065b3667667] to avoid the problem now and when Avatica is upgraded to 1.12.0. It was an invalid assumption about isValid. was (Author: risdenk): [~julianhyde] Fixed Calcite in [https://git-wip-us.apache.org/repos/asf?p=calcite.git;a=commit;h=542d51265d683dfd736c5e04f556e065b3667667] to avoid the problem now and when Avatica is upgraded to 1.12.0. It was an invalid assumption about isValid. > Release Avatica 1.12 > > > Key: CALCITE-2330 > URL: https://issues.apache.org/jira/browse/CALCITE-2330 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Francis Chuang >Priority: Major > Fix For: avatica-1.12.0 > > > Release Avatica 1.12. > We are targeting the second week of June for release; last release (1.11) was > March 2018 and the one before (1.10) that was May 2017. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2303) Support DECADE time unit in EXTRACT function
[
https://issues.apache.org/jira/browse/CALCITE-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495820#comment-16495820
]
Julian Hyde commented on CALCITE-2303:
--
Since {{EXTRACT(DOW FROM ...)}} is different from {{fn DAYOFWEEK(...)}} they're
not in conflict. Let's write tests for both, and do the right thing for both.
The only conflict is if the same expression gives different results on
different databases. Then we'd have to use a compatibility mode. Or state in
the doc whose semantics we are using.
I'm just about to commit the change to Avatica. Please let me know whether I
have a green light. I don't want to do this twice. Reviewing has been a lot of
work because we need to check both Calcite and Avatica sides.
> Support DECADE time unit in EXTRACT function
>
>
> Key: CALCITE-2303
> URL: https://issues.apache.org/jira/browse/CALCITE-2303
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Sergey Nuyanzin
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> Here CALCITE-1177 were supported new units
> however such test
> {code:java}
> @Test public void testDecadeFunction() throws Exception {
> ExpressionChecker checker = new ExpressionChecker()
> .addExpr("EXTRACT(DECADE FROM ts)", 199L)
> ;
> checker.buildRunAndCheck();
> }
> {code}
> failed like
> Extract for time unit: DECADE not supported!
> {noformat}
> SQL:>
> SELECT EXTRACT(DECADE FROM ts) FROM PCOLLECTION
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> validateAndConvert
> INFO: SQL:
> SELECT EXTRACT(DECADE FROM `PCOLLECTION`.`ts`)
> FROM `PCOLLECTION` AS `PCOLLECTION`
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> convertToBeamRel
> INFO: SQLPlan>
> LogicalProject(EXPR$0=[EXTRACT(FLAG(DECADE), $0)])
> BeamIOSourceRel(table=[[PCOLLECTION]])
> java.lang.RuntimeException:
> org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
> supported!
> at
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlBuiltinFunctionsIntegrationTestBase$ExpressionChecker.buildRunAndCheck(BeamSqlBuiltinFunctionsIntegrationTestBase.java:167)
> at
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlDateFunctionsIntegrationTest.testDecadeFunction(BeamSqlDateFunctionsIntegrationTest.java:66)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.beam.sdk.testing.TestPipeline$1.evaluate(TestPipeline.java:317)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
> supported!
> at
>
[jira] [Commented] (CALCITE-2336) SqlValidatorImpl throws java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CALCITE-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495809#comment-16495809
]
Julian Hyde commented on CALCITE-2336:
--
Try replacing {{new BasicSqlType}} with a method call into the type factory. We
rely on types being canonized.
> SqlValidatorImpl throws java.lang.IndexOutOfBoundsException
> ---
>
> Key: CALCITE-2336
> URL: https://issues.apache.org/jira/browse/CALCITE-2336
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Fei Xu
>Assignee: Julian Hyde
>Priority: Major
>
> I register a table "users" with a single column, age. And try to insert two
> columns into the "users".
> {code:java}
> rootSchema = Frameworks.createRootSchema(true);
> rootSchema.add("USERS", new AbstractTable() {
> @Override public RelDataType getRowType(final RelDataTypeFactory
> typeFactory) {
> RelDataTypeFactory.FieldInfoBuilder builder = typeFactory.builder();
> builder.add("age", new BasicSqlType(new RelDataTypeSystemImpl() {},
> SqlTypeName.CHAR));
> return builder.build();
> }
> });
> final FrameworkConfig config = Frameworks.newConfigBuilder()
> .parserConfig(SqlParser.Config.DEFAULT)
> .defaultSchema(rootSchema)
> .build();
> planner = Frameworks.getPlanner(config);
> dataContext = new MyDataContext(planner);
> SqlNode parse =
> planner.parse("insert into users select y, x\n"
> + "from (values (1, 'a'), (2, 'b'), (3, 'c')) as t(x, y)\n"
> + "where x > 1");
> SqlNode validate = planner.validate(parse);
> {code}
> Apparently, I want to see some error message like:
> {code:java}
> Number of INSERT target columns (1) does not equal number of source items (2)
> {code}
> But actually, I got message:
> {code:java}
> org.apache.calcite.tools.ValidationException:
> java.lang.IndexOutOfBoundsException: index (1) must be less than size (1)
> {code}
> which was confused.
> Then I debug the code in SqlValidatorImpl#validateSelectList method.
>
> {code:java}
> protected RelDataType validateSelectList(
> final SqlNodeList selectItems,
> SqlSelect select,
> RelDataType targetRowType) {
> // First pass, ensure that aliases are unique. "*" and "TABLE.*" items
> // are ignored.
> // Validate SELECT list. Expand terms of the form "*" or "TABLE.*".
> final SqlValidatorScope selectScope = getSelectScope(select);
> final List expandedSelectItems = new ArrayList<>();
> final Set aliases = Sets.newHashSet();
> final List> fieldList = new ArrayList<>();
> for (int i = 0; i < selectItems.size(); i++) {
> SqlNode selectItem = selectItems.get(i);
> if (selectItem instanceof SqlSelect) {
> handleScalarSubQuery(
> select,
> (SqlSelect) selectItem,
> expandedSelectItems,
> aliases,
> fieldList);
> } else {
> expandSelectItem(
> selectItem,
> select,
> targetRowType.isStruct()
> && targetRowType.getFieldCount() >= i
> ? targetRowType.getFieldList().get(i).getType()
> : unknownType,
> expandedSelectItems,
> aliases,
> fieldList,
> false);
> }
> }
> {code}
> See the exception is throw from here, if selectItems's size more than
> targetRowType's field count
> {code:java}
> && targetRowType.getFieldCount() >= i
> ? targetRowType.getFieldList().get(i).getType(){code}
> When I change it to this, I get what I need.
> {code:java}
> && targetRowType.getFieldCount() - 1 >= i
> ? targetRowType.getFieldList().get(i).getType(){code}
> So is this a Bug ? Do we need fix it ?
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CALCITE-2259) Allow Java 8 syntax in source files
[
https://issues.apache.org/jira/browse/CALCITE-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde reassigned CALCITE-2259:
Assignee: Kevin Risden (was: Julian Hyde)
> Allow Java 8 syntax in source files
> ---
>
> Key: CALCITE-2259
> URL: https://issues.apache.org/jira/browse/CALCITE-2259
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Kevin Risden
>Priority: Major
> Fix For: 1.17.0
>
>
> Allow Java 8 syntax in source files.
> In core/pom.xml, I tried changing {{source=1.7 target=1.8}} to {{source=8
> target=8}} but I ran into [Janino issue
> 47|https://github.com/janino-compiler/janino/issues/47]. (Thanks,
> [~vvysotskyi], for logging that issue.)
> When this is fixed, we will be able to use lambdas ({{->}}).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2339) JDBC adapter should transform timestamp arithmetic for target database
Julian Hyde created CALCITE-2339: Summary: JDBC adapter should transform timestamp arithmetic for target database Key: CALCITE-2339 URL: https://issues.apache.org/jira/browse/CALCITE-2339 Project: Calcite Issue Type: Bug Reporter: Julian Hyde Assignee: Julian Hyde Attachments: Datetime Addition - Calcite.pdf JDBC adapter should transform timestamp arithmetic for target database. There are two ways in Calcite to add intervals to timestamps: the TIMESTAMP_ADD function and the " + " operator. The attached document (authored by James Doung) describes their pros and cons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2338) Reconsider the externally visible api of RexSimplify
[ https://issues.apache.org/jira/browse/CALCITE-2338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495623#comment-16495623 ] Julian Hyde commented on CALCITE-2338: -- Methods like simplifyOrs are public because we don’t want to constantly deconstruct and reconstruct RexCalls. RexSimplify is on the code path every time a rule creates. project or filter, so it must be efficient. Especially when an expression has already been simplified. I don’t think there are very many such calls. > Reconsider the externally visible api of RexSimplify > > > Key: CALCITE-2338 > URL: https://issues.apache.org/jira/browse/CALCITE-2338 > Project: Calcite > Issue Type: Bug >Reporter: Zoltan Haindrich >Assignee: Zoltan Haindrich >Priority: Major > > Currently many lower level simplification methods are visible. > While I was porting CALCITE-2247 to a branch near 1.16 I've bumped into an > issue because of the fact that by calling a specific simplify method may > leave out some otherwise applicable simplifications. > For master there is already an extra safety feature by the presence of > CALCITE-2205; it seems like using less entry points may even lead to better > simplifications - by changing this; a filter have been removed. > https://github.com/kgyrtkirk/calcite/commit/2e29a659792f6bd9419dc0f97bf5a3bdd9f6f2cc -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2294) Allow customization for AvaticaServerConfiguration for plugging new authentication mechanisms
[
https://issues.apache.org/jira/browse/CALCITE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495465#comment-16495465
]
ASF GitHub Bot commented on CALCITE-2294:
-
Github user joshelser commented on the issue:
https://github.com/apache/calcite-avatica/pull/48
Cool, this looks good to me after you latest patchset, @karanmehta93. Will
try to get this merged today.
> Allow customization for AvaticaServerConfiguration for plugging new
> authentication mechanisms
> -
>
> Key: CALCITE-2294
> URL: https://issues.apache.org/jira/browse/CALCITE-2294
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Karan Mehta
>Priority: Major
> Fix For: avatica-1.12.0
>
>
> {{AvaticaServerConfiguration}} is currently only created if authentication
> mechanism such as {{BASIC, DIGEST or SPNEGO}} is provided. We can change it
> to a builder pattern to create this object and provide a way for users to
> plugin their own security configuration.
> An example here can be using it for custom config that supports MTLS.
> Thanks [~alexaraujo] for suggesting this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2338) Reconsider the externally visible api of RexSimplify
Zoltan Haindrich created CALCITE-2338: - Summary: Reconsider the externally visible api of RexSimplify Key: CALCITE-2338 URL: https://issues.apache.org/jira/browse/CALCITE-2338 Project: Calcite Issue Type: Bug Reporter: Zoltan Haindrich Assignee: Zoltan Haindrich Currently many lower level simplification methods are visible. While I was porting CALCITE-2247 to a branch near 1.16 I've bumped into an issue because of the fact that by calling a specific simplify method may leave out some otherwise applicable simplifications. For master there is already an extra safety feature by the presence of CALCITE-2205; it seems like using less entry points may even lead to better simplifications - by changing this; a filter have been removed. https://github.com/kgyrtkirk/calcite/commit/2e29a659792f6bd9419dc0f97bf5a3bdd9f6f2cc -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CALCITE-2266) Implement SQL 2016 JSON functions
[ https://issues.apache.org/jira/browse/CALCITE-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior reassigned CALCITE-2266: - Assignee: (was: Julian Hyde) > Implement SQL 2016 JSON functions > - > > Key: CALCITE-2266 > URL: https://issues.apache.org/jira/browse/CALCITE-2266 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Michael Mior >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2266) Implement SQL 2016 JSON functions
[ https://issues.apache.org/jira/browse/CALCITE-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495119#comment-16495119 ] Michael Mior edited comment on CALCITE-2266 at 5/30/18 1:06 PM: AFAIK, this is not currently being worked on. I've unassigned to myself to make that clear. (Sorry [~julianhyde] for the intermediate assignment to you, now unassigned.) was (Author: michaelmior): AFAIK, this is not currently being worked on. I've unassigned to myself to make that clear. > Implement SQL 2016 JSON functions > - > > Key: CALCITE-2266 > URL: https://issues.apache.org/jira/browse/CALCITE-2266 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Michael Mior >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CALCITE-2266) Implement SQL 2016 JSON functions
[ https://issues.apache.org/jira/browse/CALCITE-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior reassigned CALCITE-2266: - Assignee: Julian Hyde (was: Michael Mior) > Implement SQL 2016 JSON functions > - > > Key: CALCITE-2266 > URL: https://issues.apache.org/jira/browse/CALCITE-2266 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Michael Mior >Assignee: Julian Hyde >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2266) Implement SQL 2016 JSON functions
[ https://issues.apache.org/jira/browse/CALCITE-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495119#comment-16495119 ] Michael Mior commented on CALCITE-2266: --- AFAIK, this is not currently being worked on. I've unassigned to myself to make that clear. > Implement SQL 2016 JSON functions > - > > Key: CALCITE-2266 > URL: https://issues.apache.org/jira/browse/CALCITE-2266 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2337) Release Calcite 1.17.0
Volodymyr Vysotskyi created CALCITE-2337: Summary: Release Calcite 1.17.0 Key: CALCITE-2337 URL: https://issues.apache.org/jira/browse/CALCITE-2337 Project: Calcite Issue Type: Task Reporter: Volodymyr Vysotskyi Assignee: Julian Hyde Fix For: 1.17.0 Release Calcite 1.17.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2336) SqlValidatorImpl throws java.lang.IndexOutOfBoundsException
Fei Xu created CALCITE-2336:
---
Summary: SqlValidatorImpl throws
java.lang.IndexOutOfBoundsException
Key: CALCITE-2336
URL: https://issues.apache.org/jira/browse/CALCITE-2336
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Fei Xu
Assignee: Julian Hyde
I register a table "users" with a single column, age. And try to insert two
columns into the "users".
{code:java}
rootSchema = Frameworks.createRootSchema(true);
rootSchema.add("USERS", new AbstractTable() {
@Override public RelDataType getRowType(final RelDataTypeFactory
typeFactory) {
RelDataTypeFactory.FieldInfoBuilder builder = typeFactory.builder();
builder.add("age", new BasicSqlType(new RelDataTypeSystemImpl() {},
SqlTypeName.CHAR));
return builder.build();
}
});
final FrameworkConfig config = Frameworks.newConfigBuilder()
.parserConfig(SqlParser.Config.DEFAULT)
.defaultSchema(rootSchema)
.build();
planner = Frameworks.getPlanner(config);
dataContext = new MyDataContext(planner);
SqlNode parse =
planner.parse("insert into users select y, x\n"
+ "from (values (1, 'a'), (2, 'b'), (3, 'c')) as t(x, y)\n"
+ "where x > 1");
SqlNode validate = planner.validate(parse);
{code}
Apparently, I want to see some error message like:
{code:java}
Number of INSERT target columns (1) does not equal number of source items (2)
{code}
But actually, I got message:
{code:java}
org.apache.calcite.tools.ValidationException:
java.lang.IndexOutOfBoundsException: index (1) must be less than size (1)
{code}
which was confused.
Then I debug the code in SqlValidatorImpl#validateSelectList method.
{code:java}
protected RelDataType validateSelectList(
final SqlNodeList selectItems,
SqlSelect select,
RelDataType targetRowType) {
// First pass, ensure that aliases are unique. "*" and "TABLE.*" items
// are ignored.
// Validate SELECT list. Expand terms of the form "*" or "TABLE.*".
final SqlValidatorScope selectScope = getSelectScope(select);
final List expandedSelectItems = new ArrayList<>();
final Set aliases = Sets.newHashSet();
final List> fieldList = new ArrayList<>();
for (int i = 0; i < selectItems.size(); i++) {
SqlNode selectItem = selectItems.get(i);
if (selectItem instanceof SqlSelect) {
handleScalarSubQuery(
select,
(SqlSelect) selectItem,
expandedSelectItems,
aliases,
fieldList);
} else {
expandSelectItem(
selectItem,
select,
targetRowType.isStruct()
&& targetRowType.getFieldCount() >= i
? targetRowType.getFieldList().get(i).getType()
: unknownType,
expandedSelectItems,
aliases,
fieldList,
false);
}
}
{code}
See the exception is throw from here, if selectItems's size more than
targetRowType's field count
{code:java}
&& targetRowType.getFieldCount() >= i
? targetRowType.getFieldList().get(i).getType(){code}
When I change it to this, I get what I need.
{code:java}
&& targetRowType.getFieldCount() - 1 >= i
? targetRowType.getFieldList().get(i).getType(){code}
So is this a Bug ? Do we need fix it ?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2327) In 3 valued logic mode (b and not b) may not be simplified to false
[ https://issues.apache.org/jira/browse/CALCITE-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16494765#comment-16494765 ] Zoltan Haindrich commented on CALCITE-2327: --- [~jcamachorodriguez] Could you take a look? I think satisfiability is another way to think about "IS TRUE" cases. > In 3 valued logic mode (b and not b) may not be simplified to false > --- > > Key: CALCITE-2327 > URL: https://issues.apache.org/jira/browse/CALCITE-2327 > Project: Calcite > Issue Type: Bug >Reporter: Zoltan Haindrich >Assignee: Zoltan Haindrich >Priority: Major > > currently its simplified to false; but that is not correct when a is unknown -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2266) Implement SQL 2016 JSON functions
[ https://issues.apache.org/jira/browse/CALCITE-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16494764#comment-16494764 ] Shuyi Chen commented on CALCITE-2266: - Hi [~michaelmior], when do you think this will be ready? The Flink community is also interested in integrating the SQL 2016 JSON functions. > Implement SQL 2016 JSON functions > - > > Key: CALCITE-2266 > URL: https://issues.apache.org/jira/browse/CALCITE-2266 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2325) Calcite can not verify a explicit cast column in some scenario
[
https://issues.apache.org/jira/browse/CALCITE-2325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16494728#comment-16494728
]
Yuzhao Chen edited comment on CALCITE-2325 at 5/30/18 6:06 AM:
---
[~julianhyde]
I have found the reason, this is because the RexToLixTranslator did not decide
if a int operand is null then casted to decimal type, have fixed in PR:
https://github.com/apache/calcite/pull/706
was (Author: danny0405):
[~julianhyde]
I have found the reason, this is because the RexToLixTranslator did not decide
if a int operand is null then casted to decimal type, have fixed in PR:
https://github.com/apache/calcite/pull/706
> Calcite can not verify a explicit cast column in some scenario
> --
>
> Key: CALCITE-2325
> URL: https://issues.apache.org/jira/browse/CALCITE-2325
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Yuzhao Chen
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> In now calcite core, there is a test case in agg.ig in line467:
> {code:java}
> select deptno / 2 + 1 as half1, count(*) as c
> from emp
> group by rollup(deptno / 2, gender), rollup(substring(ename FROM 1 FOR
> 1));{code}
> But if we add in an explicit cast:
> {code:java}
> select cast(deptno as decimal) / 2 + 1 as half1, count(*) as c
> from emp
> group by rollup(deptno / 2, gender), rollup(substring(ename FROM 1 FOR
> 1));{code}
> it will throw an error:
>
> {code:java}
> Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1,
> column 13 to line 1, column 18: Expression 'DEPTNO' is not being grouped
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:810)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:795)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4749)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:117)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:41)
> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:344)
> at
> org.apache.calcite.sql.util.SqlBasicVisitor$ArgHandlerImpl.visitChild(SqlBasicVisitor.java:123)
> at org.apache.calcite.sql.SqlOperator.acceptCall(SqlOperator.java:859)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:212)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:41)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> at
> org.apache.calcite.sql.util.SqlBasicVisitor$ArgHandlerImpl.visitChild(SqlBasicVisitor.java:123)
> at org.apache.calcite.sql.SqlOperator.acceptCall(SqlOperator.java:859)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:212)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:41)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> at
> org.apache.calcite.sql.util.SqlBasicVisitor$ArgHandlerImpl.visitChild(SqlBasicVisitor.java:123)
> at org.apache.calcite.sql.SqlOperator.acceptCall(SqlOperator.java:859)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:212)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:41)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> at
> org.apache.calcite.sql.util.SqlBasicVisitor$ArgHandlerImpl.visitChild(SqlBasicVisitor.java:123)
> at org.apache.calcite.sql.SqlAsOperator.acceptCall(SqlAsOperator.java:121)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:212)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:41)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> at
> org.apache.calcite.sql.validate.AggregatingSelectScope.checkAggregateExpr(AggregatingSelectScope.java:231)
> at
> org.apache.calcite.sql.validate.AggregatingSelectScope.validateExpr(AggregatingSelectScope.java:240)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateExpr(SqlValidatorImpl.java:4071)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4045)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3259)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> at
>
[jira] [Commented] (CALCITE-2325) Calcite can not verify a explicit cast column in some scenario
[
https://issues.apache.org/jira/browse/CALCITE-2325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16494728#comment-16494728
]
Yuzhao Chen commented on CALCITE-2325:
--
[~julianhyde]
I have found the reason, this is because the RexToLixTranslator did not decide
if a int operand is null then casted to decimal type, have fixed in PR:
https://github.com/apache/calcite/pull/706
> Calcite can not verify a explicit cast column in some scenario
> --
>
> Key: CALCITE-2325
> URL: https://issues.apache.org/jira/browse/CALCITE-2325
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Yuzhao Chen
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> In now calcite core, there is a test case in agg.ig in line467:
> {code:java}
> select deptno / 2 + 1 as half1, count(*) as c
> from emp
> group by rollup(deptno / 2, gender), rollup(substring(ename FROM 1 FOR
> 1));{code}
> But if we add in an explicit cast:
> {code:java}
> select cast(deptno as decimal) / 2 + 1 as half1, count(*) as c
> from emp
> group by rollup(deptno / 2, gender), rollup(substring(ename FROM 1 FOR
> 1));{code}
> it will throw an error:
>
> {code:java}
> Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1,
> column 13 to line 1, column 18: Expression 'DEPTNO' is not being grouped
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:810)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:795)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4749)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:117)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:41)
> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:344)
> at
> org.apache.calcite.sql.util.SqlBasicVisitor$ArgHandlerImpl.visitChild(SqlBasicVisitor.java:123)
> at org.apache.calcite.sql.SqlOperator.acceptCall(SqlOperator.java:859)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:212)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:41)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> at
> org.apache.calcite.sql.util.SqlBasicVisitor$ArgHandlerImpl.visitChild(SqlBasicVisitor.java:123)
> at org.apache.calcite.sql.SqlOperator.acceptCall(SqlOperator.java:859)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:212)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:41)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> at
> org.apache.calcite.sql.util.SqlBasicVisitor$ArgHandlerImpl.visitChild(SqlBasicVisitor.java:123)
> at org.apache.calcite.sql.SqlOperator.acceptCall(SqlOperator.java:859)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:212)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:41)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> at
> org.apache.calcite.sql.util.SqlBasicVisitor$ArgHandlerImpl.visitChild(SqlBasicVisitor.java:123)
> at org.apache.calcite.sql.SqlAsOperator.acceptCall(SqlAsOperator.java:121)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:212)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:41)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> at
> org.apache.calcite.sql.validate.AggregatingSelectScope.checkAggregateExpr(AggregatingSelectScope.java:231)
> at
> org.apache.calcite.sql.validate.AggregatingSelectScope.validateExpr(AggregatingSelectScope.java:240)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateExpr(SqlValidatorImpl.java:4071)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4045)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3259)
> 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:972)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:948)
> at
[jira] [Commented] (CALCITE-2302) Implicit type cast support
[
https://issues.apache.org/jira/browse/CALCITE-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16494723#comment-16494723
]
Yuzhao Chen commented on CALCITE-2302:
--
hi, [~julianhyde]
I have made a PR here
[CALCITE-2302|https://github.com/apache/calcite/pull/706], really appreciate
that you can give me some suggestions.
> Implicit type cast support
> --
>
> Key: CALCITE-2302
> URL: https://issues.apache.org/jira/browse/CALCITE-2302
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: Yuzhao Chen
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> Now many DBs have support implicit type cast, eg: SqlServer, Oracle, Hive.
> Implicit type cast is an useful function for many cases, So we should support
> this.
> I checkout Calcite code and found that:
> # Now we use a validator to validate our operands types[ through kinds of
> namespaces and scopes ]
> # Most of the validations will finally goes to
> {code:java}
> SqlOperator.validateOperands
> {code}
> # which will use validation logic defined in corresponding
> SqlOperandTypeChecker
> What i'm confused about is where should i put the implicit type cast logic
> in? I figured out 2 ways:
> # Supply a tool class/rules to add casts into a parsed SqlNode tree which
> will then go through the validation logic later on.
> # Unleash the validation logic in kinds of SqlOperandTypeChecker, then
> modify the RelNode/RexNodes tree converted from a validated SqlNode tree to
> add in casts through custom RelOptRules.
> So guys, which of the 2 ways should i go, or if there are better way to do
> this?
> I need your help.
>
> Updated 18-05-30:
> Hi guys, i have made a PR in [https://github.com/apache/calcite/pull/706,]
> This is design doc: [Calcite Implicit Type Cast
> Design|https://docs.google.com/document/d/1g2RUnLXyp_LjUlO-wbblKuP5hqEu3a_2Mt2k4dh6RwU/edit?usp=sharing].
> This is the conversion types mapping: [Conversion Types
> Mapping|https://docs.google.com/spreadsheets/d/1GhleX5h5W8-kJKh7NMJ4vtoE78pwfaZRJl88ULX_MgU/edit?usp=sharing].
> I really appreciate your suggestions, thx.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
