[jira] [Comment Edited] (CALCITE-3970) Table-valued function TUMBLE uses non-standard syntax
[ https://issues.apache.org/jira/browse/CALCITE-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17106470#comment-17106470 ] Rui Wang edited comment on CALCITE-3970 at 5/13/20, 5:10 PM: - >Julian: So, how about allowing TABLE as an alternative to CURSOR, and >deprecating CURSOR with an eye to eventually removing it? I also didn't find the reference of CURSOR, and then what's the SQL semantics of it becomes not clear to me. So deprecate it from the syntax makes sense to me. I tried to dig into CURSOR implementation and I find it makes sense. E.g. Within a scope there is a list of CURSORS, and then in other places we can use RexCorrelVariable to refer to CURSORS. CURSORS, for example, can be converted to Rel's input. This fits table function implementation: table function has table parameters, which becomes CURSORS and later becomes TableFunctionScan's inputs. And in runtime, based on a RexCorrelVariable, table function impl will know which input in TableFunctionScan to use. So keep CURSOR idea in implementation seems useful. > Danny: what kind of rex node should we translate the `col` column of table > my_table I think the suggestion here [1] is a working approach. See my description of CURSOR implementation above. However to adopt the implementation of [1], there will be some non-trivial changes required. A small attempt to summarize the idea by using CURSOR in table functions and TableFunctionScan: {code:java} SqlNode: FROM: TableFunction: [TABLE[name]]: During conversion: FROM: CURSORS:[SELECT * FROM name] TableFunction: [CURSOR$0]: After conversion to Rels: TableFunctionScan: inputs: [source1[type: a BIGINT], source2[type: b VARCHAR]] table_function: [RexCorrelVariable(source1, type: a bigint)] {code} [1]: https://issues.apache.org/jira/browse/CALCITE-3955?focusedCommentId=17097014=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17097014 was (Author: amaliujia): >Julian: So, how about allowing TABLE as an alternative to CURSOR, and >deprecating CURSOR with an eye to eventually removing it? I also didn't find the reference of CURSOR, and then what's the SQL semantics of it becomes not clear to me. So deprecate it from the syntax makes sense to me. I tried to dig into CURSOR implementation and I find it makes sense. E.g. Within a scope there is a list of CURSORS, and then in other places we can use RexCorrelVariable to refer to CURSORS. CURSORS, for example, can be converted to Rel's input. This fits table function implementation: table function has table parameters, which becomes CURSORS and later becomes TableFunctionScan's inputs. And in runtime, based on a RexCorrelVariable, table function impl will know which input in TableFunctionScan to use. So keep CURSOR idea in implementation seems useful. > Danny: what kind of rex node should we translate the `col` column of table > my_table I think the suggestion here [1] is a working approach. See my description of CURSOR implementation above. However to adopt the implementation of [1], there will be some non-trivial changes required. A small attempt to summarize the idea by using CURSOR in table functions and TableFunctionScan: {code:java} SqlNode: FROM: TableFunction: [TABLE[name]]: During conversion: FROM: CURSORS:[SELECT * FROM name] TableFunction: [CURSOR$0]: After conversion to Rels: TableFunctionScan: inputs: [source1[type: a BIGINT], source2[type: b VARCHAR]] table_function: TUMBLE(RexCorrelVariable(source1, type: a bigint), ...) {code} [1]: https://issues.apache.org/jira/browse/CALCITE-3955?focusedCommentId=17097014=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17097014 > Table-valued function TUMBLE uses non-standard syntax > - > > Key: CALCITE-3970 > URL: https://issues.apache.org/jira/browse/CALCITE-3970 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.22.0 >Reporter: Viliam Durina >Priority: Major > > The currently supported syntax is this: > {code:java} > SELECT * FROM TABLE(TUMBLE(TABLE my_table, ... > {code} > But the SQL standard specifies that {{my_table}} must be in parentheses, such > as here: > {code:java} > SELECT * FROM TABLE(TUMBLE(TABLE(my_table), ... > {code} > The second syntax is currently rejected with: > {code:none} > Exception in thread "main" org.apache.calcite.sql.parser.SqlParseException: > Encountered "(" at line 1, column 33. > Was expecting one of: > ... > ... > ... > ... > ... > {code} > I'm not sure if the currently supported syntax is optional, but I think it's > not. > I followed this document: >
[jira] [Comment Edited] (CALCITE-3970) Table-valued function TUMBLE uses non-standard syntax
[ https://issues.apache.org/jira/browse/CALCITE-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17106470#comment-17106470 ] Rui Wang edited comment on CALCITE-3970 at 5/13/20, 5:09 PM: - >Julian: So, how about allowing TABLE as an alternative to CURSOR, and >deprecating CURSOR with an eye to eventually removing it? I also didn't find the reference of CURSOR, and then what's the SQL semantics of it becomes not clear to me. So deprecate it from the syntax makes sense to me. I tried to dig into CURSOR implementation and I find it makes sense. E.g. Within a scope there is a list of CURSORS, and then in other places we can use RexCorrelVariable to refer to CURSORS. CURSORS, for example, can be converted to Rel's input. This fits table function implementation: table function has table parameters, which becomes CURSORS and later becomes TableFunctionScan's inputs. And in runtime, based on a RexCorrelVariable, table function impl will know which input in TableFunctionScan to use. So keep CURSOR idea in implementation seems useful. > Danny: what kind of rex node should we translate the `col` column of table > my_table I think the suggestion here [1] is a working approach. See my description of CURSOR implementation above. However to adopt the implementation of [1], there will be some non-trivial changes required. A small attempt to summarize the idea by using CURSOR in table functions and TableFunctionScan: {code:java} SqlNode: FROM: TableFunction: [TABLE[name]]: During conversion: FROM: CURSORS:[SELECT * FROM name] TableFunction: [CURSOR$0]: After conversion to Rels: TableFunctionScan: inputs: [source1[type: a BIGINT], source2[type: b VARCHAR]] table_function: TUMBLE(RexCorrelVariable(source1, type: a bigint), ...) {code} [1]: https://issues.apache.org/jira/browse/CALCITE-3955?focusedCommentId=17097014=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17097014 was (Author: amaliujia): >Julian: So, how about allowing TABLE as an alternative to CURSOR, and >deprecating CURSOR with an eye to eventually removing it? I also didn't find the reference of CURSOR, and then what's the SQL semantics of it becomes not clear to me. So deprecate it from the syntax makes sense to me. I tried to dig into CURSOR implementation and I find it makes sense. E.g. Within a scope there is a list of CURSORS, and then in other places we can use RexCorrelVariable to refer to CURSORS. CURSORS, for example, can be converted to Rel's input. This fits table function implementation: table function has table parameters, which becomes CURSORS and later becomes TableFunctionScan's inputs. And in runtime, based on a RexNode, table function impl will know which input in TableFunctionScan to use. So keep CURSOR idea in implementation seems useful. > Danny: what kind of rex node should we translate the `col` column of table > my_table I think the suggestion here [1] is a working approach. See my description of CURSOR implementation above. However to adopt the implementation of [1], there will be some non-trivial changes required. A small attempt to summarize the idea by using CURSOR in table functions and TableFunctionScan: {code:java} SqlNode: FROM: TableFunction: [TABLE[name]]: During conversion: FROM: CURSORS:[SELECT * FROM name] TableFunction: [CURSOR$0]: After conversion to Rels: TableFunctionScan: inputs: [source1[type: a BIGINT], source2[type: b VARCHAR]] table_function: TUMBLE(RexCorrelVariable(source1, type: a bigint), ...) {code} [1]: https://issues.apache.org/jira/browse/CALCITE-3955?focusedCommentId=17097014=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17097014 > Table-valued function TUMBLE uses non-standard syntax > - > > Key: CALCITE-3970 > URL: https://issues.apache.org/jira/browse/CALCITE-3970 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.22.0 >Reporter: Viliam Durina >Priority: Major > > The currently supported syntax is this: > {code:java} > SELECT * FROM TABLE(TUMBLE(TABLE my_table, ... > {code} > But the SQL standard specifies that {{my_table}} must be in parentheses, such > as here: > {code:java} > SELECT * FROM TABLE(TUMBLE(TABLE(my_table), ... > {code} > The second syntax is currently rejected with: > {code:none} > Exception in thread "main" org.apache.calcite.sql.parser.SqlParseException: > Encountered "(" at line 1, column 33. > Was expecting one of: > ... > ... > ... > ... > ... > {code} > I'm not sure if the currently supported syntax is optional, but I think it's > not. > I followed this document: >
[jira] [Comment Edited] (CALCITE-3970) Table-valued function TUMBLE uses non-standard syntax
[ https://issues.apache.org/jira/browse/CALCITE-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17106470#comment-17106470 ] Rui Wang edited comment on CALCITE-3970 at 5/13/20, 5:05 PM: - >Julian: So, how about allowing TABLE as an alternative to CURSOR, and >deprecating CURSOR with an eye to eventually removing it? I also didn't find the reference of CURSOR, and then what's the SQL semantics of it becomes not clear to me. So deprecate it from the syntax makes sense to me. I tried to dig into CURSOR implementation and I find it makes sense. E.g. Within a scope there is a list of CURSORS, and then in other places we can use RexCorrelVariable to refer to CURSORS. CURSORS, for example, can be converted to Rel's input. This fits table function implementation: table function has table parameters, which becomes CURSORS and later becomes TableFunctionScan's inputs. And in runtime, based on a RexNode, table function impl will know which input in TableFunctionScan to use. So keep CURSOR idea in implementation seems useful. > Danny: what kind of rex node should we translate the `col` column of table > my_table I think the suggestion here [1] is a working approach. See my description of CURSOR implementation above. However to adopt the implementation of [1], there will be some non-trivial changes required. A small attempt to summarize the idea by using CURSOR in table functions and TableFunctionScan: {code:java} SqlNode: FROM: TableFunction: [TABLE[name]]: During conversion: FROM: CURSORS:[SELECT * FROM name] TableFunction: [CURSOR$0]: After conversion to Rels: TableFunctionScan: inputs: [source1[type: a BIGINT], source2[type: b VARCHAR]] table_function: TUMBLE(RexCorrelVariable(source1, type: a bigint), ...) {code} [1]: https://issues.apache.org/jira/browse/CALCITE-3955?focusedCommentId=17097014=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17097014 was (Author: amaliujia): >Julian: So, how about allowing TABLE as an alternative to CURSOR, and >deprecating CURSOR with an eye to eventually removing it? I also didn't find the reference of CURSOR, and then what's the SQL semantics of it becomes not clear to me. So deprecate it from the syntax makes sense to me. I tried to dig into CURSOR implementation and I find it makes sense. E.g. Within a scope there is a list of CURSORS, and then in other places we can use RexCorrelVariable to refer to CURSORS. CURSORS, for example, can be converted to Rel's input. This fits table function implementation: table function has table parameters, which becomes CURSORS and later becomes TableFunctionScan's inputs. And in runtime, based on a RexNode, table function impl will know which input in TableFunctionScan to use. So keep CURSOR idea in implementation seems useful. > Danny: what kind of rex node should we translate the `col` column of table > my_table I think the suggestion here [1] is a working approach. See my description of CURSOR implementation above. However to adopt the implementation of [1], there will be some non-trivial changes required. A small attempt to summarize the idea by using CURSOR in table functions and TableFunctionScan: {code:java} SqlNode: FROM: CURSORS:[] TableFunction: [TABLE[name]]: During conversion: FROM: CURSORS:[SELECT * FROM name] TableFunction: [CURSOR$0]: After conversion to Rels: TableFunctionScan: inputs: [source1[type: a BIGINT], source2[type: b VARCHAR]] table_function: TUMBLE(RexCorrelVariable(source1, type: a bigint), ...) {code} [1]: https://issues.apache.org/jira/browse/CALCITE-3955?focusedCommentId=17097014=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17097014 > Table-valued function TUMBLE uses non-standard syntax > - > > Key: CALCITE-3970 > URL: https://issues.apache.org/jira/browse/CALCITE-3970 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.22.0 >Reporter: Viliam Durina >Priority: Major > > The currently supported syntax is this: > {code:java} > SELECT * FROM TABLE(TUMBLE(TABLE my_table, ... > {code} > But the SQL standard specifies that {{my_table}} must be in parentheses, such > as here: > {code:java} > SELECT * FROM TABLE(TUMBLE(TABLE(my_table), ... > {code} > The second syntax is currently rejected with: > {code:none} > Exception in thread "main" org.apache.calcite.sql.parser.SqlParseException: > Encountered "(" at line 1, column 33. > Was expecting one of: > ... > ... > ... > ... > ... > {code} > I'm not sure if the currently supported syntax is optional, but I think it's > not. > I followed this document: >
[jira] [Comment Edited] (CALCITE-3970) Table-valued function TUMBLE uses non-standard syntax
[ https://issues.apache.org/jira/browse/CALCITE-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17106470#comment-17106470 ] Rui Wang edited comment on CALCITE-3970 at 5/13/20, 5:04 PM: - >Julian: So, how about allowing TABLE as an alternative to CURSOR, and >deprecating CURSOR with an eye to eventually removing it? I also didn't find the reference of CURSOR, and then what's the SQL semantics of it becomes not clear to me. So deprecate it from the syntax makes sense to me. I tried to dig into CURSOR implementation and I find it makes sense. E.g. Within a scope there is a list of CURSORS, and then in other places we can use RexCorrelVariable to refer to CURSORS. CURSORS, for example, can be converted to Rel's input. This fits table function implementation: table function has table parameters, which becomes CURSORS and later becomes TableFunctionScan's inputs. And in runtime, based on a RexNode, table function impl will know which input in TableFunctionScan to use. So keep CURSOR idea in implementation seems useful. > Danny: what kind of rex node should we translate the `col` column of table > my_table I think the suggestion here [1] is a working approach. See my description of CURSOR implementation above. However to adopt the implementation of [1], there will be some non-trivial changes required. A small attempt to summarize the idea by using CURSOR in table functions and TableFunctionScan: {code:java} SqlNode: FROM: CURSORS:[] TableFunction: [TABLE[name]]: During conversion: FROM: CURSORS:[SELECT * FROM name] TableFunction: [CURSOR$0]: After conversion to Rels: TableFunctionScan: inputs: [source1[type: a BIGINT], source2[type: b VARCHAR]] table_function: TUMBLE(RexCorrelVariable(source1, type: a bigint), ...) {code} [1]: https://issues.apache.org/jira/browse/CALCITE-3955?focusedCommentId=17097014=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17097014 was (Author: amaliujia): >Julian: So, how about allowing TABLE as an alternative to CURSOR, and >deprecating CURSOR with an eye to eventually removing it? I also didn't find the reference of CURSOR, and then what's the SQL semantics of it becomes not clear to me. So deprecate it from the syntax makes sense to me. I tried to dig into CURSOR implementation and I find it makes sense. E.g. Within a scope there is a list of CURSORS, and then in other places we can use RexCorrelVariable to refer to CURSORS. CURSORS, for example, can be converted to Rel's input. This fits table function implementation: table function has table parameters, which becomes CURSORS and later becomes TableFunctionScan's inputs. And in runtime, based on a RexNode, table function impl will know which input in TableFunctionScan to use. So keep CURSOR idea in implementation seems useful. > Danny: what kind of rex node should we translate the `col` column of table > my_table I think the suggestion here [1] is a working approach. See my description of CURSOR implementation above. However to adopt the implementation of [1], there will be some non-trivial changes required. A small attempt to summarize the idea by using CURSOR in table functions and TableFunctionScan: SqlNode: FROM: CURSORS:[] TableFunction: [TABLE[name]]: During conversion: FROM: CURSORS:[SELECT * FROM name] TableFunction: [CURSOR$0]: After conversion to Rels: TableFunctionScan: inputs: [source1[type: a bigint], source2[type: b string]] table_function: TUMBLE(RexCorrelVariable(source1, type: a bigint), ...) [1]: https://issues.apache.org/jira/browse/CALCITE-3955?focusedCommentId=17097014=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17097014 > Table-valued function TUMBLE uses non-standard syntax > - > > Key: CALCITE-3970 > URL: https://issues.apache.org/jira/browse/CALCITE-3970 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.22.0 >Reporter: Viliam Durina >Priority: Major > > The currently supported syntax is this: > {code:java} > SELECT * FROM TABLE(TUMBLE(TABLE my_table, ... > {code} > But the SQL standard specifies that {{my_table}} must be in parentheses, such > as here: > {code:java} > SELECT * FROM TABLE(TUMBLE(TABLE(my_table), ... > {code} > The second syntax is currently rejected with: > {code:none} > Exception in thread "main" org.apache.calcite.sql.parser.SqlParseException: > Encountered "(" at line 1, column 33. > Was expecting one of: > ... > ... > ... > ... > ... > {code} > I'm not sure if the currently supported syntax is optional, but I think it's > not. > I followed this document: >
[jira] [Comment Edited] (CALCITE-3970) Table-valued function TUMBLE uses non-standard syntax
[ https://issues.apache.org/jira/browse/CALCITE-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17106470#comment-17106470 ] Rui Wang edited comment on CALCITE-3970 at 5/13/20, 5:03 PM: - >Julian: So, how about allowing TABLE as an alternative to CURSOR, and >deprecating CURSOR with an eye to eventually removing it? I also didn't find the reference of CURSOR, and then what's the SQL semantics of it becomes not clear to me. So deprecate it from the syntax makes sense to me. I tried to dig into CURSOR implementation and I find it makes sense. E.g. Within a scope there is a list of CURSORS, and then in other places we can use RexCorrelVariable to refer to CURSORS. CURSORS, for example, can be converted to Rel's input. This fits table function implementation: table function has table parameters, which becomes CURSORS and later becomes TableFunctionScan's inputs. And in runtime, based on a RexNode, table function impl will know which input in TableFunctionScan to use. So keep CURSOR idea in implementation seems useful. > Danny: what kind of rex node should we translate the `col` column of table > my_table I think the suggestion here [1] is a working approach. See my description of CURSOR implementation above. However to adopt the implementation of [1], there will be some non-trivial changes required. A small attempt to summarize the idea by using CURSOR in table functions and TableFunctionScan: SqlNode: FROM: CURSORS:[] TableFunction: [TABLE[name]]: During conversion: FROM: CURSORS:[SELECT * FROM name] TableFunction: [CURSOR$0]: After conversion to Rels: TableFunctionScan: inputs: [source1[type: a bigint], source2[type: b string]] table_function: TUMBLE(RexCorrelVariable(source1, type: a bigint), ...) [1]: https://issues.apache.org/jira/browse/CALCITE-3955?focusedCommentId=17097014=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17097014 was (Author: amaliujia): >Julian: So, how about allowing TABLE as an alternative to CURSOR, and >deprecating CURSOR with an eye to eventually removing it? I also didn't find the reference of CURSOR, and then what's the SQL semantics of it becomes not clear to me. So deprecate it from the syntax makes sense to me. I tried to dig into CURSOR implementation and I find it makes sense. E.g. Within a scope there is a list of CURSORS, and then in other places we can use RexNode to refer to CURSORS. CURSORS, for example, can be converted to Rel's input. This fits table function implementation: table function has table parameters, which becomes CURSORS and later becomes TableFunctionScan's inputs. And in runtime, based on a RexNode, table function impl will know which input in TableFunctionScan to use. So keep CURSOR idea in implementation seems useful. > Danny: what kind of rex node should we translate the `col` column of table > my_table I think the suggestion here [1] is a working approach. See my description of CURSOR implementation above. However to adopt the implementation of [1], there will be some non-trivial changes required. [1]: https://issues.apache.org/jira/browse/CALCITE-3955?focusedCommentId=17097014=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17097014 > Table-valued function TUMBLE uses non-standard syntax > - > > Key: CALCITE-3970 > URL: https://issues.apache.org/jira/browse/CALCITE-3970 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.22.0 >Reporter: Viliam Durina >Priority: Major > > The currently supported syntax is this: > {code:java} > SELECT * FROM TABLE(TUMBLE(TABLE my_table, ... > {code} > But the SQL standard specifies that {{my_table}} must be in parentheses, such > as here: > {code:java} > SELECT * FROM TABLE(TUMBLE(TABLE(my_table), ... > {code} > The second syntax is currently rejected with: > {code:none} > Exception in thread "main" org.apache.calcite.sql.parser.SqlParseException: > Encountered "(" at line 1, column 33. > Was expecting one of: > ... > ... > ... > ... > ... > {code} > I'm not sure if the currently supported syntax is optional, but I think it's > not. > I followed this document: > [http://standards.iso.org/ittf/PubliclyAvailableStandards/c069776_ISO_IEC_TR_19075-7_2017.zip] > The {{TABLE}} clause acts in both ways: (1) to convert a table value to a > table object (when used in the {{FROM}} clause to convert the function > result) and (2) to convert a table object to a table value (when used to > convert arguments to a function). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3970) Table-valued function TUMBLE uses non-standard syntax
[ https://issues.apache.org/jira/browse/CALCITE-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17100541#comment-17100541 ] Viliam Durina edited comment on CALCITE-3970 at 5/6/20, 8:00 AM: - See the section "8.6": {code:java} ::= TABLE | TABLE | {code} also specifies that a subquery also uses TABLE keyword, not CURSOR (see section 8.6.2): {code:java} FROMTABLE (Ptf ( TABLE ( SELECT * FROM Emp ) ) ) AS P {code} All the examples in the spec use {{TABLE(foo)}} syntax. was (Author: vilo): See the section "8.6": {code:java} ::= TABLE | TABLE | {code} also specifies that a subquery also uses TABLE keyword, not CURSOR (see section 8.6.2): {code:java} FROMTABLE (Ptf ( TABLE ( SELECT * FROM Emp ) ) ) AS P {code} > Table-valued function TUMBLE uses non-standard syntax > - > > Key: CALCITE-3970 > URL: https://issues.apache.org/jira/browse/CALCITE-3970 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.22.0 >Reporter: Viliam Durina >Priority: Major > > The currently supported syntax is this: > {code:java} > SELECT * FROM TABLE(TUMBLE(TABLE my_table, ... > {code} > But the SQL standard specifies that {{my_table}} must be in parentheses, such > as here: > {code:java} > SELECT * FROM TABLE(TUMBLE(TABLE(my_table), ... > {code} > The second syntax is currently rejected with: > {code:none} > Exception in thread "main" org.apache.calcite.sql.parser.SqlParseException: > Encountered "(" at line 1, column 33. > Was expecting one of: > ... > ... > ... > ... > ... > {code} > I'm not sure if the currently supported syntax is optional, but I think it's > not. > I followed this document: > [http://standards.iso.org/ittf/PubliclyAvailableStandards/c069776_ISO_IEC_TR_19075-7_2017.zip] > The {{TABLE}} clause acts in both ways: (1) to convert a table value to a > table object (when used in the {{FROM}} clause to convert the function > result) and (2) to convert a table object to a table value (when used to > convert arguments to a function). -- This message was sent by Atlassian Jira (v8.3.4#803005)