[jira] [Commented] (CALCITE-1235) Push down LIMIT in unfiltered Cassandra queries
[
https://issues.apache.org/jira/browse/CALCITE-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290354#comment-15290354
]
Michael Mior commented on CALCITE-1235:
---
To clarify, in the currently committed version of the adapter, pushing down
sort + limit does not work because {{CassandraSortRule}} only ever seems to see
a {{Sort}} without a fetch.
> Push down LIMIT in unfiltered Cassandra queries
> ---
>
> Key: CALCITE-1235
> URL: https://issues.apache.org/jira/browse/CALCITE-1235
> Project: Calcite
> Issue Type: Improvement
> Components: cassandra
>Affects Versions: 1.7.0
>Reporter: Michael Mior
>Assignee: Michael Mior
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1235) Push down LIMIT in unfiltered Cassandra queries
[
https://issues.apache.org/jira/browse/CALCITE-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290343#comment-15290343
]
Michael Mior commented on CALCITE-1235:
---
Unfortunately I don't see a good way to get rid of rules involving
{{EnumerableLimit}}. The problem is that to push down sort + limit there needs
to be an instance of {{CassandraFilter}}. However, at the point where this rule
has been applied, it seems like {{EnumerableFilterRule}} has already been
applied. Also, I'm going to create a separate JIRA to deal with pushing down
offset.
> Push down LIMIT in unfiltered Cassandra queries
> ---
>
> Key: CALCITE-1235
> URL: https://issues.apache.org/jira/browse/CALCITE-1235
> Project: Calcite
> Issue Type: Improvement
> Components: cassandra
>Affects Versions: 1.7.0
>Reporter: Michael Mior
>Assignee: Michael Mior
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1242) Allow configuration of maximum allowed value for maxRowCount
[ https://issues.apache.org/jira/browse/CALCITE-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290206#comment-15290206 ] Josh Elser commented on CALCITE-1242: - bq. “maximum number of rows for a statement” should be handled inside the SQL query string. This is intentionally disjoint. You can push the LIMIT down to the database already. This is meant to limit the number of results at the JDBC level. For example, users can limit the number of results you want, while some application running queries from users can set an upper limit on the number of rows returned. They have different purposes. > Allow configuration of maximum allowed value for maxRowCount > > > Key: CALCITE-1242 > URL: https://issues.apache.org/jira/browse/CALCITE-1242 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Duo Xu >Assignee: Josh Elser > Fix For: avatica-1.9.0 > > > There are several APIs having the maxRowCount parameter. Currently this > setting is hard coded in Avatica as 100. So if the user set maxRowCount > 100 > in PrepareAndExecuteRequest, for example, the server will still only return > 100 results. So the APIs are currently broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1241) Add a freemarker variable for adding non reserved keywords to Parser.jj template
[
https://issues.apache.org/jira/browse/CALCITE-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290052#comment-15290052
]
Venki Korukanti commented on CALCITE-1241:
--
Updated the patch in PR. One change: Used {{getTokens}} and deciding whether
the token is a reserved keyword or not. {{getJdbcKeywords}} is returning
hardcoded SQL 92 standard reserved keyword list.
> Add a freemarker variable for adding non reserved keywords to Parser.jj
> template
>
>
> Key: CALCITE-1241
> URL: https://issues.apache.org/jira/browse/CALCITE-1241
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Venki Korukanti
>Assignee: Julian Hyde
> Fix For: 1.8.0
>
>
> Currently Calcite parser allows customizing parser grammar for supporting new
> Sql constructs (ex. {{SHOW TABLES}} or {{CREATE TABLE ... AS QUERY}}) through
> freemarker template variables. There is a freemarker template variable to
> allow new keywords, but all these keywords are added as reserved keywords
> which are not allowed as identifiers unless escaped with {{`}} (or configured
> casing character).
> This JIRA is to add a freemarker template variable for adding non reserved
> keywords list.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1242) Allow configuration of maximum allowed value for maxRowCount
[ https://issues.apache.org/jira/browse/CALCITE-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290034#comment-15290034 ] Duo Xu commented on CALCITE-1242: - or avoid confusion, maxRowCount should only be translated to “number of rows per frame”, “maximum number of rows for a statement” should be handled inside the SQL query string. > Allow configuration of maximum allowed value for maxRowCount > > > Key: CALCITE-1242 > URL: https://issues.apache.org/jira/browse/CALCITE-1242 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Duo Xu >Assignee: Josh Elser > Fix For: avatica-1.9.0 > > > There are several APIs having the maxRowCount parameter. Currently this > setting is hard coded in Avatica as 100. So if the user set maxRowCount > 100 > in PrepareAndExecuteRequest, for example, the server will still only return > 100 results. So the APIs are currently broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1242) Allow configuration of maximum allowed value for maxRowCount
[ https://issues.apache.org/jira/browse/CALCITE-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290030#comment-15290030 ] Duo Xu commented on CALCITE-1242: - I would suggest we expose two parameters instead of a single "maxRowCount". “maximum number of rows for a statement”: this is equivalent to "limit" in sql, “number of rows per frame”: this is equivalent to "how many rows it returns in single http call" Currently maxRowCount is mixed with these two. > Allow configuration of maximum allowed value for maxRowCount > > > Key: CALCITE-1242 > URL: https://issues.apache.org/jira/browse/CALCITE-1242 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Duo Xu >Assignee: Josh Elser > Fix For: avatica-1.9.0 > > > There are several APIs having the maxRowCount parameter. Currently this > setting is hard coded in Avatica as 100. So if the user set maxRowCount > 100 > in PrepareAndExecuteRequest, for example, the server will still only return > 100 results. So the APIs are currently broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1243) max_row_count in Proto file should be signed int
[
https://issues.apache.org/jira/browse/CALCITE-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289966#comment-15289966
]
Josh Elser commented on CALCITE-1243:
-
Turns out that the Avatica (java) client is sending negative values over the
unsigned attribute. Oops. Because java doesn't have signed types, we just
didn't realize that we were doing it. We should correct this before 1.8.0.
> max_row_count in Proto file should be signed int
>
>
> Key: CALCITE-1243
> URL: https://issues.apache.org/jira/browse/CALCITE-1243
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Duo Xu
>Assignee: Josh Elser
>Priority: Blocker
> Fix For: avatica-1.8.0
>
>
> Looking at the source code, the maxRowCount is signed. And based on the code
> comments,
> /** Creates a result set with maxRowCount.
>*
>* If {@code maxRowCount} is -2 ({@link JdbcMeta#UNLIMITED_COUNT}),
>* returns an unlimited number of rows in a single frame; any other
>* negative value (typically -1) returns an unlimited number of rows
>* in frames of the default frame size. */
> we can pass -2 to return all the rows in a single batch. But the proto file
> define this parameter as unsigned. We need to make it consistent with the
> internal code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1243) max_row_count in Proto file should be signed int
[
https://issues.apache.org/jira/browse/CALCITE-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1243:
Fix Version/s: (was: avatica-1.9.0)
avatica-1.8.0
> max_row_count in Proto file should be signed int
>
>
> Key: CALCITE-1243
> URL: https://issues.apache.org/jira/browse/CALCITE-1243
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Duo Xu
>Assignee: Josh Elser
> Fix For: avatica-1.8.0
>
>
> Looking at the source code, the maxRowCount is signed. And based on the code
> comments,
> /** Creates a result set with maxRowCount.
>*
>* If {@code maxRowCount} is -2 ({@link JdbcMeta#UNLIMITED_COUNT}),
>* returns an unlimited number of rows in a single frame; any other
>* negative value (typically -1) returns an unlimited number of rows
>* in frames of the default frame size. */
> we can pass -2 to return all the rows in a single batch. But the proto file
> define this parameter as unsigned. We need to make it consistent with the
> internal code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1243) max_row_count in Proto file should be signed int
[
https://issues.apache.org/jira/browse/CALCITE-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1243:
Priority: Blocker (was: Major)
> max_row_count in Proto file should be signed int
>
>
> Key: CALCITE-1243
> URL: https://issues.apache.org/jira/browse/CALCITE-1243
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Duo Xu
>Assignee: Josh Elser
>Priority: Blocker
> Fix For: avatica-1.8.0
>
>
> Looking at the source code, the maxRowCount is signed. And based on the code
> comments,
> /** Creates a result set with maxRowCount.
>*
>* If {@code maxRowCount} is -2 ({@link JdbcMeta#UNLIMITED_COUNT}),
>* returns an unlimited number of rows in a single frame; any other
>* negative value (typically -1) returns an unlimited number of rows
>* in frames of the default frame size. */
> we can pass -2 to return all the rows in a single batch. But the proto file
> define this parameter as unsigned. We need to make it consistent with the
> internal code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1244) `offset` is ignored in FetchRequest
[
https://issues.apache.org/jira/browse/CALCITE-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289931#comment-15289931
]
Francis Chuang commented on CALCITE-1244:
-
This looks very similar to (if not duplicates)
[CALCITE-1181|https://issues.apache.org/jira/browse/CALCITE-1181]
> `offset` is ignored in FetchRequest
> ---
>
> Key: CALCITE-1244
> URL: https://issues.apache.org/jira/browse/CALCITE-1244
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
> Fix For: avatica-1.9.0
>
>
> In looking into some issues reported by [~onpduo], we both noticed that
> {{FetchRequest.offset}} is never actually used by the server.
> We should make sure the semantics on this value are clear (is it an offset
> from the beginning of the ResultSet or the current position of the
> ResultSet?) and make sure it is used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1244) `offset` is ignored in FetchRequest
Josh Elser created CALCITE-1244:
---
Summary: `offset` is ignored in FetchRequest
Key: CALCITE-1244
URL: https://issues.apache.org/jira/browse/CALCITE-1244
Project: Calcite
Issue Type: Bug
Components: avatica
Reporter: Josh Elser
Fix For: avatica-1.9.0
In looking into some issues reported by [~onpduo], we both noticed that
{{FetchRequest.offset}} is never actually used by the server.
We should make sure the semantics on this value are clear (is it an offset from
the beginning of the ResultSet or the current position of the ResultSet?) and
make sure it is used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1241) Add a freemarker variable for adding non reserved keywords to Parser.jj template
[
https://issues.apache.org/jira/browse/CALCITE-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289896#comment-15289896
]
Julian Hyde commented on CALCITE-1241:
--
Yes, please add a test to SqlParserTest as part of the patch. Call
{{getJdbcKeywords}} (as in testMetadata), split on commas, remove non-reserved
keywords, and you have the list of reserved keywords. Compare that with a list
hard-coded in the test.
Drill should consider calling SqlParserTest from within its test suite (one or
two tests might need to be overridden or disabled, but it would still provide
useful information). But anyway that is definitely part of this task.
> Add a freemarker variable for adding non reserved keywords to Parser.jj
> template
>
>
> Key: CALCITE-1241
> URL: https://issues.apache.org/jira/browse/CALCITE-1241
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Venki Korukanti
>Assignee: Julian Hyde
> Fix For: 1.8.0
>
>
> Currently Calcite parser allows customizing parser grammar for supporting new
> Sql constructs (ex. {{SHOW TABLES}} or {{CREATE TABLE ... AS QUERY}}) through
> freemarker template variables. There is a freemarker template variable to
> allow new keywords, but all these keywords are added as reserved keywords
> which are not allowed as identifiers unless escaped with {{`}} (or configured
> casing character).
> This JIRA is to add a freemarker template variable for adding non reserved
> keywords list.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1241) Add a freemarker variable for adding non reserved keywords to Parser.jj template
[
https://issues.apache.org/jira/browse/CALCITE-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289879#comment-15289879
]
Venki Korukanti commented on CALCITE-1241:
--
I think it makes sense to have a test in Calcite to check for new keywords and
throw error if the test keyword list is not updated or forgot to add the new
keywords to non-reserved keyword list. Testing the extended parsers is
difficult unless they have their own tests which extend the list provided in
the Calcite test. We can make the test code in extended parser smaller by
providing the calcite keyword list. Let me know if you want the test with the
patch.
> Add a freemarker variable for adding non reserved keywords to Parser.jj
> template
>
>
> Key: CALCITE-1241
> URL: https://issues.apache.org/jira/browse/CALCITE-1241
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Venki Korukanti
>Assignee: Julian Hyde
> Fix For: 1.8.0
>
>
> Currently Calcite parser allows customizing parser grammar for supporting new
> Sql constructs (ex. {{SHOW TABLES}} or {{CREATE TABLE ... AS QUERY}}) through
> freemarker template variables. There is a freemarker template variable to
> allow new keywords, but all these keywords are added as reserved keywords
> which are not allowed as identifiers unless escaped with {{`}} (or configured
> casing character).
> This JIRA is to add a freemarker template variable for adding non reserved
> keywords list.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1242) Allow configuration of maximum allowed value for maxRowCount
[
https://issues.apache.org/jira/browse/CALCITE-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289838#comment-15289838
]
Josh Elser commented on CALCITE-1242:
-
bq. Can you remind me why there is a maximum maxRowCount? Could we just remove
the limit? I'd rather not introduce configuration parameters.
I think it predates my involvement, actually. I always assumed it was there to
prevent clients from specifying {{Long.MAX_VALUE}} and causing the server to
run out of heap space. That's what influences my assumption that we have a
configurable upper-bound on that limit (since it would be a case-by-case
basis). When we start thinking about multi-tenancy some more, this becomes
pretty important.
> Allow configuration of maximum allowed value for maxRowCount
>
>
> Key: CALCITE-1242
> URL: https://issues.apache.org/jira/browse/CALCITE-1242
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Duo Xu
>Assignee: Josh Elser
> Fix For: avatica-1.9.0
>
>
> There are several APIs having the maxRowCount parameter. Currently this
> setting is hard coded in Avatica as 100. So if the user set maxRowCount > 100
> in PrepareAndExecuteRequest, for example, the server will still only return
> 100 results. So the APIs are currently broken.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1243) max_row_count in Proto file should be signed int
[
https://issues.apache.org/jira/browse/CALCITE-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1243:
Fix Version/s: avatica-1.9.0
> max_row_count in Proto file should be signed int
>
>
> Key: CALCITE-1243
> URL: https://issues.apache.org/jira/browse/CALCITE-1243
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Duo Xu
>Assignee: Josh Elser
> Fix For: avatica-1.9.0
>
>
> Looking at the source code, the maxRowCount is signed. And based on the code
> comments,
> /** Creates a result set with maxRowCount.
>*
>* If {@code maxRowCount} is -2 ({@link JdbcMeta#UNLIMITED_COUNT}),
>* returns an unlimited number of rows in a single frame; any other
>* negative value (typically -1) returns an unlimited number of rows
>* in frames of the default frame size. */
> we can pass -2 to return all the rows in a single batch. But the proto file
> define this parameter as unsigned. We need to make it consistent with the
> internal code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1243) max_row_count in Proto file should be signed int
[
https://issues.apache.org/jira/browse/CALCITE-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1243:
-
Component/s: avatica
> max_row_count in Proto file should be signed int
>
>
> Key: CALCITE-1243
> URL: https://issues.apache.org/jira/browse/CALCITE-1243
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Duo Xu
>Assignee: Julian Hyde
>
> Looking at the source code, the maxRowCount is signed. And based on the code
> comments,
> /** Creates a result set with maxRowCount.
>*
>* If {@code maxRowCount} is -2 ({@link JdbcMeta#UNLIMITED_COUNT}),
>* returns an unlimited number of rows in a single frame; any other
>* negative value (typically -1) returns an unlimited number of rows
>* in frames of the default frame size. */
> we can pass -2 to return all the rows in a single batch. But the proto file
> define this parameter as unsigned. We need to make it consistent with the
> internal code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1243) max_row_count in Proto file should be signed int
[
https://issues.apache.org/jira/browse/CALCITE-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1243:
-
Assignee: Josh Elser (was: Julian Hyde)
> max_row_count in Proto file should be signed int
>
>
> Key: CALCITE-1243
> URL: https://issues.apache.org/jira/browse/CALCITE-1243
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Duo Xu
>Assignee: Josh Elser
>
> Looking at the source code, the maxRowCount is signed. And based on the code
> comments,
> /** Creates a result set with maxRowCount.
>*
>* If {@code maxRowCount} is -2 ({@link JdbcMeta#UNLIMITED_COUNT}),
>* returns an unlimited number of rows in a single frame; any other
>* negative value (typically -1) returns an unlimited number of rows
>* in frames of the default frame size. */
> we can pass -2 to return all the rows in a single batch. But the proto file
> define this parameter as unsigned. We need to make it consistent with the
> internal code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1241) Add a freemarker variable for adding non reserved keywords to Parser.jj template
[
https://issues.apache.org/jira/browse/CALCITE-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289805#comment-15289805
]
Julian Hyde commented on CALCITE-1241:
--
The list of reserved keywords doesn't change very often (because it comes down
from the SQL standard). A common mistake is to add a keyword and forget to add
it to the non-reserved list. Should we have a list of reserved words (in a
test, say) and a test that will break (and require manual intervention) each
time someone adds a reserved word (intentionally or otherwise).
We already have SqlParserTest.testGenerateKeyWords, which does something
similar, but doesn't check for new reserved keywords explicitly. Plus it
doesn't help projects that extend the core SQL parser, such as Drill and
Phoenix.
> Add a freemarker variable for adding non reserved keywords to Parser.jj
> template
>
>
> Key: CALCITE-1241
> URL: https://issues.apache.org/jira/browse/CALCITE-1241
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Venki Korukanti
>Assignee: Julian Hyde
> Fix For: 1.8.0
>
>
> Currently Calcite parser allows customizing parser grammar for supporting new
> Sql constructs (ex. {{SHOW TABLES}} or {{CREATE TABLE ... AS QUERY}}) through
> freemarker template variables. There is a freemarker template variable to
> allow new keywords, but all these keywords are added as reserved keywords
> which are not allowed as identifiers unless escaped with {{`}} (or configured
> casing character).
> This JIRA is to add a freemarker template variable for adding non reserved
> keywords list.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1243) max_row_count in Proto file should be signed int
Duo Xu created CALCITE-1243:
---
Summary: max_row_count in Proto file should be signed int
Key: CALCITE-1243
URL: https://issues.apache.org/jira/browse/CALCITE-1243
Project: Calcite
Issue Type: Bug
Reporter: Duo Xu
Assignee: Julian Hyde
Looking at the source code, the maxRowCount is signed. And based on the code
comments,
/** Creates a result set with maxRowCount.
*
* If {@code maxRowCount} is -2 ({@link JdbcMeta#UNLIMITED_COUNT}),
* returns an unlimited number of rows in a single frame; any other
* negative value (typically -1) returns an unlimited number of rows
* in frames of the default frame size. */
we can pass -2 to return all the rows in a single batch. But the proto file
define this parameter as unsigned. We need to make it consistent with the
internal code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1242) Allow configuration of maximum allowed value for maxRowCount
[ https://issues.apache.org/jira/browse/CALCITE-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289793#comment-15289793 ] Julian Hyde commented on CALCITE-1242: -- [~elserj] Can you remind me why there is a maximum maxRowCount? Could we just remove the limit? I'd rather not introduce configuration parameters. > Allow configuration of maximum allowed value for maxRowCount > > > Key: CALCITE-1242 > URL: https://issues.apache.org/jira/browse/CALCITE-1242 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Duo Xu >Assignee: Josh Elser > Fix For: avatica-1.9.0 > > > There are several APIs having the maxRowCount parameter. Currently this > setting is hard coded in Avatica as 100. So if the user set maxRowCount > 100 > in PrepareAndExecuteRequest, for example, the server will still only return > 100 results. So the APIs are currently broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1242) Allow configuration of maximum allowed value for maxRowCount
[ https://issues.apache.org/jira/browse/CALCITE-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-1242: Summary: Allow configuration of maximum allowed value for maxRowCount (was: Make maxRowCount configurable) > Allow configuration of maximum allowed value for maxRowCount > > > Key: CALCITE-1242 > URL: https://issues.apache.org/jira/browse/CALCITE-1242 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Duo Xu >Assignee: Josh Elser > Fix For: avatica-1.9.0 > > > There are several APIs having the maxRowCount parameter. Currently this > setting is hard coded in Avatica as 100. So if the user set maxRowCount > 100 > in PrepareAndExecuteRequest, for example, the server will still only return > 100 results. So the APIs are currently broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CALCITE-1242) Make maxRowCount configurable
[ https://issues.apache.org/jira/browse/CALCITE-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser reassigned CALCITE-1242: --- Assignee: Josh Elser (was: Julian Hyde) > Make maxRowCount configurable > - > > Key: CALCITE-1242 > URL: https://issues.apache.org/jira/browse/CALCITE-1242 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Duo Xu >Assignee: Josh Elser > Fix For: avatica-1.9.0 > > > There are several APIs having the maxRowCount parameter. Currently this > setting is hard coded in Avatica as 100. So if the user set maxRowCount > 100 > in PrepareAndExecuteRequest, for example, the server will still only return > 100 results. So the APIs are currently broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1241) Add a freemarker variable for adding non reserved keywords to Parser.jj template
[
https://issues.apache.org/jira/browse/CALCITE-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289779#comment-15289779
]
Julian Hyde commented on CALCITE-1241:
--
SQL syntax unfortunately allows expressions and queries in the same context and
there is no fixed lookahead that can distinguish which it is going to be. For
example, {{x IN (((select 1 union ...) minus ... ) ... )))}}
I don't know whether JavaCC has a performance difference depending on how you
order the alternatives. If you can change the parser such that it performs
better and gives the same results, have at it! Feel free to devise (or
generate) queries where parser performance sucks.
Your comments underscore the value of reserved keywords. I agree. They make the
parser's life much easier (and error messages easier to understand).
Unfortunately it is hard to justify adding reserved keywords. Generally we just
take the list that comes with the SQL standard.
> Add a freemarker variable for adding non reserved keywords to Parser.jj
> template
>
>
> Key: CALCITE-1241
> URL: https://issues.apache.org/jira/browse/CALCITE-1241
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Venki Korukanti
>Assignee: Julian Hyde
> Fix For: 1.8.0
>
>
> Currently Calcite parser allows customizing parser grammar for supporting new
> Sql constructs (ex. {{SHOW TABLES}} or {{CREATE TABLE ... AS QUERY}}) through
> freemarker template variables. There is a freemarker template variable to
> allow new keywords, but all these keywords are added as reserved keywords
> which are not allowed as identifiers unless escaped with {{`}} (or configured
> casing character).
> This JIRA is to add a freemarker template variable for adding non reserved
> keywords list.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1242) Make maxRowCount configurable
[ https://issues.apache.org/jira/browse/CALCITE-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289780#comment-15289780 ] Josh Elser commented on CALCITE-1242: - bq. So the APIs are currently broken. A little argumentative to call them "broken", it's just not how they work. The documentation just didn't tell you that there is a limit on how high you can set that value :) > Make maxRowCount configurable > - > > Key: CALCITE-1242 > URL: https://issues.apache.org/jira/browse/CALCITE-1242 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Duo Xu >Assignee: Julian Hyde > Fix For: avatica-1.9.0 > > > There are several APIs having the maxRowCount parameter. Currently this > setting is hard coded in Avatica as 100. So if the user set maxRowCount > 100 > in PrepareAndExecuteRequest, for example, the server will still only return > 100 results. So the APIs are currently broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1241) Add a freemarker variable for adding non reserved keywords to Parser.jj template
[
https://issues.apache.org/jira/browse/CALCITE-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1241:
-
Fix Version/s: 1.8.0
> Add a freemarker variable for adding non reserved keywords to Parser.jj
> template
>
>
> Key: CALCITE-1241
> URL: https://issues.apache.org/jira/browse/CALCITE-1241
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Venki Korukanti
>Assignee: Julian Hyde
> Fix For: 1.8.0
>
>
> Currently Calcite parser allows customizing parser grammar for supporting new
> Sql constructs (ex. {{SHOW TABLES}} or {{CREATE TABLE ... AS QUERY}}) through
> freemarker template variables. There is a freemarker template variable to
> allow new keywords, but all these keywords are added as reserved keywords
> which are not allowed as identifiers unless escaped with {{`}} (or configured
> casing character).
> This JIRA is to add a freemarker template variable for adding non reserved
> keywords list.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1242) Make maxRowCount configurable
[ https://issues.apache.org/jira/browse/CALCITE-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-1242: Component/s: avatica > Make maxRowCount configurable > - > > Key: CALCITE-1242 > URL: https://issues.apache.org/jira/browse/CALCITE-1242 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Duo Xu >Assignee: Julian Hyde > Fix For: avatica-1.9.0 > > > There are several APIs having the maxRowCount parameter. Currently this > setting is hard coded in Avatica as 100. So if the user set maxRowCount > 100 > in PrepareAndExecuteRequest, for example, the server will still only return > 100 results. So the APIs are currently broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1242) Make maxRowCount configurable
[ https://issues.apache.org/jira/browse/CALCITE-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-1242: Fix Version/s: avatica-1.9.0 > Make maxRowCount configurable > - > > Key: CALCITE-1242 > URL: https://issues.apache.org/jira/browse/CALCITE-1242 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Duo Xu >Assignee: Julian Hyde > Fix For: avatica-1.9.0 > > > There are several APIs having the maxRowCount parameter. Currently this > setting is hard coded in Avatica as 100. So if the user set maxRowCount > 100 > in PrepareAndExecuteRequest, for example, the server will still only return > 100 results. So the APIs are currently broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1242) Make maxRowCount configurable
Duo Xu created CALCITE-1242: --- Summary: Make maxRowCount configurable Key: CALCITE-1242 URL: https://issues.apache.org/jira/browse/CALCITE-1242 Project: Calcite Issue Type: Bug Reporter: Duo Xu Assignee: Julian Hyde There are several APIs having the maxRowCount parameter. Currently this setting is hard coded in Avatica as 100. So if the user set maxRowCount > 100 in PrepareAndExecuteRequest, for example, the server will still only return 100 results. So the APIs are currently broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1237) Session windows for streaming SQL
[
https://issues.apache.org/jira/browse/CALCITE-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289718#comment-15289718
]
Julian Hyde edited comment on CALCITE-1237 at 5/18/16 8:17 PM:
---
bq. Q3: I think supporting session in the GROUP BY clause is a good starting
point.
I agree, but I'll give some thought to whether it would work in {{OVER}}. For
example, does it make sense to simultaneously compute sessions partitioning by
(sourceIp) and (sourceIp, port)?
bq. Can we add functions similar to TUMBLE_START and TUMBLE_END? It would be
consistent with the other window functions and a shortcut compared to accessing
the corresponding values with first_value and last_value (given that we allow
order-dependent aggregates).
Yes.
bq. You said "Unlike the tumble function, each row belongs to precisely one
window.". Tumbling windows are non-overlapping, so tumble should be hop, right?
My mistake. I'll fix the original text.
bq. is it possible to move the additional grouping columns out of the session
function to the GROUP BY clause? This would be more similar to the definition
of TUMBLE and HOP in http://calcite.apache.org/docs/stream.html?
I thought about that. I added the extra arguments to make its semantics to be
as close as possible to a mathematical function. Some examples:
* {{FLOOR}} is a true function; its value depends only on its arguments.
* {{TUMBLE}} is a true function, although the value is a tuple consisting of
the lower and upper bound of the window.
* {{HOP}} is a little less pure. In fact, it is a mathematical function that
returns a set. The set depends only on the arguments. The GROUP BY operator
produces one sub-total row for each value in the set.
If we adopt your semantics, the {{SESSION}} "function" depends not only on its
arguments, but the set of rows that have the same {{GROUP BY}} key values. When
you describe it this way, you see that it behaves exactly like a SQL aggregate
function. The only strange thing is that we allow it in the {{GROUP BY}} clause.
By the way, under your semantics, the example looks like this:
{code}
select stream session(rowtime, interval '5' second), productId, count(*) as c
from Orders
group by session(rowtime, interval '5' second), productId
{code}
If we are to adopt your semantics, we need to think what are the implications
of allowing an aggregate function in the GROUP BY clause. I think we could make
it work. I can think other aggregate functions, such as
[NTILE|http://stackoverflow.com/questions/14355324/want-to-learn-more-on-ntile],
that you might want to include in the GROUP BY clause.
was (Author: julianhyde):
bq. Q3: I think supporting session in the GROUP BY clause is a good starting
point.
I agree, but I'll give some thought to whether it would work in {{OVER}}. For
example, does it make sense to simultaneously compute sessions partitioning by
(sourceIp) and (sourceIp, port)?
bq. Can we add functions similar to TUMBLE_START and TUMBLE_END? It would be
consistent with the other window functions and a shortcut compared to accessing
the corresponding values with first_value and last_value (given that we allow
order-dependent aggregates).
Yes.
bq. You said "Unlike the tumble function, each row belongs to precisely one
window.". Tumbling windows are non-overlapping, so tumble should be hop, right?
My mistake. I'll fix the original text.
bq. is it possible to move the additional grouping columns out of the session
function to the GROUP BY clause? This would be more similar to the definition
of TUMBLE and HOP in http://calcite.apache.org/docs/stream.html?
I thought about that. I added the extra arguments to make its semantics to be
as close as possible to a mathematical function. Some examples:
* FLOOR is a true function; its value depends only on its arguments.
* TUMBLE is a true function, although the value is a tuple consisting of the
lower and upper bound of the window.
* HOP is a little less pure, because it produces a set of values, but the set
depends only on the arguments.
If we adopt your semantics, the {{SESSION}} "function" depends not only on its
arguments, but the set of rows that have the same {{GROUP BY}} key values. When
you describe it this way, you see that it behaves exactly like a SQL aggregate
function. The only strange thing is that we allow it in the {{GROUP BY}} clause.
By the way, under your semantics, the example looks like this:
{code}
select stream session(rowtime, interval '5' second), productId, count(*) as c
from Orders
group by session(rowtime, interval '5' second), productId
{code}
If we are to adopt your semantics, we need to think what are the implications
of allowing an aggregate function in the GROUP BY clause. I think we could make
it work. I can think other aggregate functions, such as
[NTILE|http://stackoverflow.com/questions/14355324/want-to-l
[jira] [Updated] (CALCITE-1237) Session windows for streaming SQL
[
https://issues.apache.org/jira/browse/CALCITE-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1237:
-
Description:
A session window is a collection of rows whose key values, when sorted, have a
gap of at most N.
Q1. Should "at most" be "less than"?
The key type can be any type that has a minus operator, that is, numeric and
date-time.
I propose the following syntax: {{session(key [, ...]*, interval)}}. For
example:
{code}
select stream session(rowtime, productId, interval '5' second),
productId, count(*) as c
from Orders
group by session(rowtime, productId, interval '5' second),
productId
{code}
to find bursts of orders for the same product where consecutive orders are no
more than 5 seconds apart.
The first key column {{rowtime}} defines the session and must be of
numeric/date-time type, and must have monotonicity or similar in order for the
query to make progress; the other key columns (in this case {{productId}}) can
be of any type; the last column is the interval, and must be constant.
The {{session}} function returns the key value at the start of the window.
Unlike the {{hop}} function, each row belongs to precisely one window. But
{{session}} is not a true function, because its value depends on the records
flowing in the stream.
Q2. If {{session}} is used, should we allow order-dependent aggregate functions
such as {{first_value}}?
Q3. Should we allow {{session}} as a windowed aggregate function?
was:
A session window is a collection of rows whose key values, when sorted, have a
gap of at most N.
Q1. Should "at most" be "less than"?
The key type can be any type that has a minus operator, that is, numeric and
date-time.
I propose the following syntax: {{session(key [, ...]*, interval)}}. For
example:
{code}
select stream session(rowtime, productId, interval '5' second),
productId, count(*) as c
from Orders
group by session(rowtime, productId, interval '5' second),
productId
{code}
to find bursts of orders for the same product where consecutive orders are no
more than 5 seconds apart.
The first key column {{rowtime}} defines the session and must be of
numeric/date-time type, and must have monotonicity or similar in order for the
query to make progress; the other key columns (in this case {{productId}}) can
be of any type; the last column is the interval, and must be constant.
The {{session}} function returns the key value at the start of the window.
Unlike the {{tumble}} function, each row belongs to precisely one window. But
{{session}} is not a true function, because its value depends on the records
flowing in the stream.
Q2. If {{session}} is used, should we allow order-dependent aggregate functions
such as {{first_value}}?
Q3. Should we allow {{session}} as a windowed aggregate function?
> Session windows for streaming SQL
> -
>
> Key: CALCITE-1237
> URL: https://issues.apache.org/jira/browse/CALCITE-1237
> Project: Calcite
> Issue Type: Bug
> Components: stream
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> A session window is a collection of rows whose key values, when sorted, have
> a gap of at most N.
> Q1. Should "at most" be "less than"?
> The key type can be any type that has a minus operator, that is, numeric and
> date-time.
> I propose the following syntax: {{session(key [, ...]*, interval)}}. For
> example:
> {code}
> select stream session(rowtime, productId, interval '5' second),
> productId, count(*) as c
> from Orders
> group by session(rowtime, productId, interval '5' second),
> productId
> {code}
> to find bursts of orders for the same product where consecutive orders are no
> more than 5 seconds apart.
> The first key column {{rowtime}} defines the session and must be of
> numeric/date-time type, and must have monotonicity or similar in order for
> the query to make progress; the other key columns (in this case
> {{productId}}) can be of any type; the last column is the interval, and must
> be constant.
> The {{session}} function returns the key value at the start of the window.
> Unlike the {{hop}} function, each row belongs to precisely one window. But
> {{session}} is not a true function, because its value depends on the records
> flowing in the stream.
> Q2. If {{session}} is used, should we allow order-dependent aggregate
> functions such as {{first_value}}?
> Q3. Should we allow {{session}} as a windowed aggregate function?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1237) Session windows for streaming SQL
[
https://issues.apache.org/jira/browse/CALCITE-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289718#comment-15289718
]
Julian Hyde commented on CALCITE-1237:
--
bq. Q3: I think supporting session in the GROUP BY clause is a good starting
point.
I agree, but I'll give some thought to whether it would work in {{OVER}}. For
example, does it make sense to simultaneously compute sessions partitioning by
(sourceIp) and (sourceIp, port)?
bq. Can we add functions similar to TUMBLE_START and TUMBLE_END? It would be
consistent with the other window functions and a shortcut compared to accessing
the corresponding values with first_value and last_value (given that we allow
order-dependent aggregates).
Yes.
bq. You said "Unlike the tumble function, each row belongs to precisely one
window.". Tumbling windows are non-overlapping, so tumble should be hop, right?
My mistake. I'll fix the original text.
bq. is it possible to move the additional grouping columns out of the session
function to the GROUP BY clause? This would be more similar to the definition
of TUMBLE and HOP in http://calcite.apache.org/docs/stream.html?
I thought about that. I added the extra arguments to make its semantics to be
as close as possible to a mathematical function. Some examples:
* FLOOR is a true function; its value depends only on its arguments.
* TUMBLE is a true function, although the value is a tuple consisting of the
lower and upper bound of the window.
* HOP is a little less pure, because it produces a set of values, but the set
depends only on the arguments.
If we adopt your semantics, the {{SESSION}} "function" depends not only on its
arguments, but the set of rows that have the same {{GROUP BY}} key values. When
you describe it this way, you see that it behaves exactly like a SQL aggregate
function. The only strange thing is that we allow it in the {{GROUP BY}} clause.
By the way, under your semantics, the example looks like this:
{code}
select stream session(rowtime, interval '5' second), productId, count(*) as c
from Orders
group by session(rowtime, interval '5' second), productId
{code}
If we are to adopt your semantics, we need to think what are the implications
of allowing an aggregate function in the GROUP BY clause. I think we could make
it work. I can think other aggregate functions, such as
[NTILE|http://stackoverflow.com/questions/14355324/want-to-learn-more-on-ntile],
that you might want to include in the GROUP BY clause.
> Session windows for streaming SQL
> -
>
> Key: CALCITE-1237
> URL: https://issues.apache.org/jira/browse/CALCITE-1237
> Project: Calcite
> Issue Type: Bug
> Components: stream
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> A session window is a collection of rows whose key values, when sorted, have
> a gap of at most N.
> Q1. Should "at most" be "less than"?
> The key type can be any type that has a minus operator, that is, numeric and
> date-time.
> I propose the following syntax: {{session(key [, ...]*, interval)}}. For
> example:
> {code}
> select stream session(rowtime, productId, interval '5' second),
> productId, count(*) as c
> from Orders
> group by session(rowtime, productId, interval '5' second),
> productId
> {code}
> to find bursts of orders for the same product where consecutive orders are no
> more than 5 seconds apart.
> The first key column {{rowtime}} defines the session and must be of
> numeric/date-time type, and must have monotonicity or similar in order for
> the query to make progress; the other key columns (in this case
> {{productId}}) can be of any type; the last column is the interval, and must
> be constant.
> The {{session}} function returns the key value at the start of the window.
> Unlike the {{tumble}} function, each row belongs to precisely one window. But
> {{session}} is not a true function, because its value depends on the records
> flowing in the stream.
> Q2. If {{session}} is used, should we allow order-dependent aggregate
> functions such as {{first_value}}?
> Q3. Should we allow {{session}} as a windowed aggregate function?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1241) Add a freemarker variable for adding non reserved keywords to Parser.jj template
[
https://issues.apache.org/jira/browse/CALCITE-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289584#comment-15289584
]
Venki Korukanti commented on CALCITE-1241:
--
This is the most common issue, I have seen. One other thing is I encounter is:
if the first two keywords in a SQL construct are non-reserved keywords, parser
goes down the expression parsing path (as part of {{OrderedQueryOrExpr}}). So
any SQL construct need to have at least one reserved keyword in the first two
tokens. Is it better to separate out query and expression parsing into two
methods and move the expression parsing to last choice? Expression most likely
is going to have identifiers. Having it in the beginning only causes non
reserved keywords to be interpreted as identifiers.
> Add a freemarker variable for adding non reserved keywords to Parser.jj
> template
>
>
> Key: CALCITE-1241
> URL: https://issues.apache.org/jira/browse/CALCITE-1241
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Venki Korukanti
>Assignee: Julian Hyde
>
> Currently Calcite parser allows customizing parser grammar for supporting new
> Sql constructs (ex. {{SHOW TABLES}} or {{CREATE TABLE ... AS QUERY}}) through
> freemarker template variables. There is a freemarker template variable to
> allow new keywords, but all these keywords are added as reserved keywords
> which are not allowed as identifiers unless escaped with {{`}} (or configured
> casing character).
> This JIRA is to add a freemarker template variable for adding non reserved
> keywords list.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1241) Add a freemarker variable for adding non reserved keywords to Parser.jj template
[
https://issues.apache.org/jira/browse/CALCITE-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289546#comment-15289546
]
Julian Hyde commented on CALCITE-1241:
--
It makes sense, and the patch looks good. But I wonder, could we go further?
Are there any pitfalls that people run into every time they add a keyword, and
is there something we could do to make that easier?
> Add a freemarker variable for adding non reserved keywords to Parser.jj
> template
>
>
> Key: CALCITE-1241
> URL: https://issues.apache.org/jira/browse/CALCITE-1241
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Venki Korukanti
>Assignee: Julian Hyde
>
> Currently Calcite parser allows customizing parser grammar for supporting new
> Sql constructs (ex. {{SHOW TABLES}} or {{CREATE TABLE ... AS QUERY}}) through
> freemarker template variables. There is a freemarker template variable to
> allow new keywords, but all these keywords are added as reserved keywords
> which are not allowed as identifiers unless escaped with {{`}} (or configured
> casing character).
> This JIRA is to add a freemarker template variable for adding non reserved
> keywords list.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1208) Improve two-level column structure handling
[
https://issues.apache.org/jira/browse/CALCITE-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289511#comment-15289511
]
Maryann Xue commented on CALCITE-1208:
--
Hi [~jni], please check this file for a (hopefully complete) list of query
examples
https://github.com/apache/calcite/compare/master...maryannxue:calcite-1208#diff-0a6b96592dd053cb0697ea9ebfa3eea4.
Let me know if it helps. Phoenix follows the hierarchical column naming
convention of HBase, which is ColumnFamilyName.ColumnName, but this is only for
name resolving. We would like to have the a flat structure as table type.
> Improve two-level column structure handling
> ---
>
> Key: CALCITE-1208
> URL: https://issues.apache.org/jira/browse/CALCITE-1208
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.7.0
>Reporter: Maryann Xue
>Assignee: Maryann Xue
>
> Calcite now has support for nested column structure in parsing and
> validation, by representing the inner-level columns as a RexFieldAccess based
> on a RexInputRef. Meanwhile it does not flatten the inner level structure in
> wildcard expansion, which would then cause an UnsupportedOperationException
> in Avatica.
>
> The idea is to take into account this nested structure in column resolving,
> but to flatten the structure when translating to RelNode/RexNode.
> For example, if the table structure is defined as
> {code}VARCHAR K0,
> VARCHAR C1,
> RecordType(INTEGER C0, INTEGER C1) F0,
> RecordType(INTEGER C0, INTEGER C2) F1{code}
> , it should be viewed as a flat type like
> {code}VARCHAR K0,
> VARCHAR C1,
> INTEGER F0.C0,
> INTEGER F0.C1,
> INTEGER F1.C0,
> INTEGER F1.C2{code}
> , so that:
> 1) Column reference "K0" is translated as {{$0}}
> 2) Column reference "F0.C1" is translated as {{$3}}
> 3) Wildcard "*" is translated as: {{$0, $1, $2, $3, $4, $5}}
> 4) Complex-column wildcard "F1.*", which is translated as {{$2, $3}}
> And we would like to resolve columns based on the following rules (here we
> only consider the "suffix" part of the qualified names, which means the table
> resolving is already done by this time):
> a) A two-part column name is matched with its first-level column name and its
> second-level column name. For example, "F1.C0" corresponds to $4; "F1,X" will
> throw a column not found error.
> b) A single-part column name is matched against non-nested columns first, and
> if no matches, it is then matched against those second-level column names.
> For example, "C1" will be matched as "$1" instead of "$3", since non-nested
> columns have a higher priority; "C2" will be matched as "$5"; "C0" will lead
> to an ambiguous column error, since it exists under both "F0" and "F1".
> c) We would also like to have a way for defining "default first-level column"
> so that it has a precedence in column resolving over other first-level
> columns. For example, if "F0" is defined as default, "C0" will not cause an
> ambiguous column error, but instead be matched as "$2".
> d) Reference to first-level column only without wildcard is not allowed,
> e.g., "F1".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1241) Add a freemarker variable for adding non reserved keywords to Parser.jj template
Venki Korukanti created CALCITE-1241:
Summary: Add a freemarker variable for adding non reserved
keywords to Parser.jj template
Key: CALCITE-1241
URL: https://issues.apache.org/jira/browse/CALCITE-1241
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Venki Korukanti
Assignee: Julian Hyde
Currently Calcite parser allows customizing parser grammar for supporting new
Sql constructs (ex. {{SHOW TABLES}} or {{CREATE TABLE ... AS QUERY}}) through
freemarker template variables. There is a freemarker template variable to allow
new keywords, but all these keywords are added as reserved keywords which are
not allowed as identifiers unless escaped with {{`}} (or configured casing
character).
This JIRA is to add a freemarker template variable for adding non reserved
keywords list.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1237) Session windows for streaming SQL
[
https://issues.apache.org/jira/browse/CALCITE-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15288687#comment-15288687
]
Fabian Hueske commented on CALCITE-1237:
Hi [~julianhyde], thanks for the proposal! I like it.
Answering your questions first:
Q1: In my opinion "at most" is more intuitive than "less than".
Q2: I'm in favor of allowing order-dependent aggregates
Q3: I think supporting {{session}} in the {{GROUP BY}} clause is a good
starting point.
I have a few questions / suggestions as well:
- is it possible to move the additional grouping columns out of the {{session}}
function to the {{GROUP BY}} clause? This would be more similar to the
definition of {{TUMBLE}} and {{HOP}} in
http://calcite.apache.org/docs/stream.html?
- Can we add functions similar to {{TUMBLE_START}} and {{TUMBLE_END}}? It would
be consistent with the other window functions and a shortcut compared to
accessing the corresponding values with {{first_value}} and {{last_value}}
(given that we allow order-dependent aggregates).
- You said "Unlike the tumble function, each row belongs to precisely one
window.". Tumbling windows are non-overlapping, so {{tumble}} should be
{{hop}}, right?
> Session windows for streaming SQL
> -
>
> Key: CALCITE-1237
> URL: https://issues.apache.org/jira/browse/CALCITE-1237
> Project: Calcite
> Issue Type: Bug
> Components: stream
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> A session window is a collection of rows whose key values, when sorted, have
> a gap of at most N.
> Q1. Should "at most" be "less than"?
> The key type can be any type that has a minus operator, that is, numeric and
> date-time.
> I propose the following syntax: {{session(key [, ...]*, interval)}}. For
> example:
> {code}
> select stream session(rowtime, productId, interval '5' second),
> productId, count(*) as c
> from Orders
> group by session(rowtime, productId, interval '5' second),
> productId
> {code}
> to find bursts of orders for the same product where consecutive orders are no
> more than 5 seconds apart.
> The first key column {{rowtime}} defines the session and must be of
> numeric/date-time type, and must have monotonicity or similar in order for
> the query to make progress; the other key columns (in this case
> {{productId}}) can be of any type; the last column is the interval, and must
> be constant.
> The {{session}} function returns the key value at the start of the window.
> Unlike the {{tumble}} function, each row belongs to precisely one window. But
> {{session}} is not a true function, because its value depends on the records
> flowing in the stream.
> Q2. If {{session}} is used, should we allow order-dependent aggregate
> functions such as {{first_value}}?
> Q3. Should we allow {{session}} as a windowed aggregate function?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
