[jira] [Commented] (CALCITE-1938) First Apache release for Avatica Go
[
https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125192#comment-16125192
]
Francis Chuang commented on CALCITE-1938:
-
{quote}
Couldn't something be done to figure out the flavor of database and what it
supports? I think we have driver information already sent back from the server.
Maybe it's as simple as returning that back? Syntax shouldn't matter for the
driver itself, just the sql provided, no?
{quote}
>From the RpcMetadata message, I only see that the server_address is returned.
>However, I don't think this is a blocker, because if we have a test matrix
>like in travis-ci, we can execute both the Phoenix and HSQLdb tests separately
>by switching against a environment variable.
The driver does not care about the syntax itself, however in the tests, we
execute statements against Phoenix using `UPSERT ...`. Since HSQLdb uses
insert/update, we would need to rewrite the SQL statements in the appropriate
syntax. There is also a test that inserts into a table using all the various
Phoenix data types and selects them to see that the data is being saved and
read correctly, and we'd need a seperate one for HSQLdb.
These are not insurmountable challenges. Since all the integration tests are in
driver_test.go, we could turn that into driver_phoenix_test.go and
driver_hsqldb_test.go and have the different flavors run depending on what the
environment variable AVATICA_FLAVOR is set to.
{quote}
Anyways, I don't think it's a good use of our time to try to deploy a full
hbase installation on the ASF infra. It tends to be over-taxed already – a
minimal testing environment is the best plan of action.
{quote}
I agree that it's not productive to set up an HBase install, but if we are
using jenkins, is it possible to use a docker image as a service? If so, my
hbase-phoenix-all-in-one image spins up a container that has hbase-standalone,
phoenix, pqs and tephra enabled. This should require about the same effort as
testing against the avatica-hsqldb image.
> First Apache release for Avatica Go
> ---
>
> Key: CALCITE-1938
> URL: https://issues.apache.org/jira/browse/CALCITE-1938
> Project: Calcite
> Issue Type: Bug
> Components: avatica-go
>Reporter: Julian Hyde
>Assignee: Francis Chuang
>
> Make a release for Avatica Go.
> Release number is TBD.
> This will be the first Apache release for Avacica Go, so expect more
> diligence / issues than usual.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1938) First Apache release for Avatica Go
[ https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125183#comment-16125183 ] Josh Elser commented on CALCITE-1938: - bq. I'd definitely keep the tests running against Phoenix at the very least since the driver advertises Phoenix support Support for Phoenix's use of Avatica should be secondary to making sure that it works against Avatica "proper". bq. It's possible to duplicate the tests and run them twice, once on Phoenix and once on avatica + hsqldb, but I am wondering if the payoff is worth it (tests would probably take twice as long to run). Couldn't something be done to figure out the flavor of database and what it supports? I think we have driver information already sent back from the server. Maybe it's as simple as returning that back? Syntax shouldn't matter for the driver itself, just the sql provided, no? Anyways, I don't think it's a good use of our time to try to deploy a full hbase installation on the ASF infra. It tends to be over-taxed already -- a minimal testing environment is the best plan of action. > First Apache release for Avatica Go > --- > > Key: CALCITE-1938 > URL: https://issues.apache.org/jira/browse/CALCITE-1938 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Reporter: Julian Hyde >Assignee: Francis Chuang > > Make a release for Avatica Go. > Release number is TBD. > This will be the first Apache release for Avacica Go, so expect more > diligence / issues than usual. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1897) Support operator "%" as an alternative to "mod"
[ https://issues.apache.org/jira/browse/CALCITE-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125178#comment-16125178 ] sunjincheng commented on CALCITE-1897: -- Hi, [~julianhyde]Thanks for your review. and sorry for late reply. I had update the PR. according your comments. the changes as follows: 1. Change the symbol `REMAINDER ` to `PERCENT_REMAINDER ` ; 2. Mod function using `SqlKind.MOD`; 3. Add ModPrecedenceTest; 4. Add limitation of conformance levels.(MYQL_5 & LENIENT) 5. Uses same code-generation code for both `%` and `mod function`. but i am not sure if the changes are 100% match your comments. I am grateful if can review the changes again. About your comments, i have a question: Why only allow % in the MYSQL and LENIENT. How can i know that before you told me. Is there some document you can share me to study ? changes reference: 1. http://docs.oracle.com/cd/E11882_01/server.112/e41084/functions101.htm#SQLRF00668 > Support operator "%" as an alternative to "mod" > --- > > Key: CALCITE-1897 > URL: https://issues.apache.org/jira/browse/CALCITE-1897 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: sunjincheng >Assignee: sunjincheng > > Currently the following sql is not supported. > SELECT a%3 FROM T > We get the exception: > > Caused by: org.apache.calcite.sql.parser.SqlParseException: Lexical > error at line 1, column 9. Encountered: "%" (37), after : "" > at > org.apache.calcite.sql.parser.impl.SqlParserImpl.convertException(SqlParserImpl.java:396) > at > org.apache.calcite.sql.parser.impl.SqlParserImpl.normalizeException(SqlParserImpl.java:129) > In this JIRA. I'll fix this by support operator "%" as an alternative to > "mod". > Similar https://issues.apache.org/jira/browse/CALCITE-1374 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1938) First Apache release for Avatica Go
[ https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125177#comment-16125177 ] Francis Chuang commented on CALCITE-1938: - There are some "traditional" unit tests to test parsing the dsn when setting up the db connection: https://github.com/apache/calcite-avatica-go/blob/master/dsn_test.go But other than that, since this is a database/sql it makes sense to test everything else against a real database, rather than try and mock the database. Testing against the calcite-avatica image is possible, however, I chose Phoenix when the driver was first written because: - I am using the driver against Phoenix in my projects. - The avatica + hsqldb image did not exist back then. - I needed to test the Phoenix error codes. I'd definitely keep the tests running against Phoenix at the very least since the driver advertises Phoenix support. It should be possible to add support for testing against avatica + hsqldb, however, from what I can see, Phoenix is not using Calcite yet, so the SQL syntax is sightly different (UPSERT vs INSERT/Update) and the data types supported are different. It's possible to duplicate the tests and run them twice, once on Phoenix and once on avatica + hsqldb, but I am wondering if the payoff is worth it (tests would probably take twice as long to run). > First Apache release for Avatica Go > --- > > Key: CALCITE-1938 > URL: https://issues.apache.org/jira/browse/CALCITE-1938 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Reporter: Julian Hyde >Assignee: Francis Chuang > > Make a release for Avatica Go. > Release number is TBD. > This will be the first Apache release for Avacica Go, so expect more > diligence / issues than usual. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1911) Support WITHIN clause in MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125149#comment-16125149
]
Dian Fu commented on CALCITE-1911:
--
Make sense. Have updated the tests for INTERVAL.
> Support WITHIN clause in MATCH_RECOGNIZE
>
>
> Key: CALCITE-1911
> URL: https://issues.apache.org/jira/browse/CALCITE-1911
> Project: Calcite
> Issue Type: Bug
>Reporter: Dian Fu
>Assignee: Julian Hyde
> Labels: match
>
> Window is an important feature for pattern detection, it defines the time
> duration for the events to match a pattern. Here is an example from
> [doc|https://docs.oracle.com/middleware/1213/eventprocessing/cql-reference/GUID-34D4968E-C55A-4BC7-B1CE-C84B202217BD.htm#CQLLR2119]:
> {code}
> SELECT T.Ac2, T.Bc2, T.Cc2
> FROM S
> MATCH_RECOGNIZE(
> MEASURES A.c2 as Ac2, B.c2 as Bc2, C.c2 as Cc2
> PATTERN (A (B+ | C)) within 3000 milliseconds
> DEFINE
> A as A.c1=10 or A.c1=25,
> B as B.c1=20 or B.c1=15 or B.c1=25,
> C as C.c1=15
> ) as T
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1935) Reference implementation for MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125140#comment-16125140
]
Zhiqiang He commented on CALCITE-1935:
--
I do not think we can use regular expression support. It is too simple and some
case maybe can not support.
I think I can develop it used NFA. but it is very complex. It may be cost a
long time to develop.
I will create some subtask when I familiar with corpus data sets.
[~julianhyde] can you give me a test case in calcite project for corpus data
sets. I want to kown how to develop it and which interface will be implametion.
thanks.
> Reference implementation for MATCH_RECOGNIZE
>
>
> Key: CALCITE-1935
> URL: https://issues.apache.org/jira/browse/CALCITE-1935
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> We now have comprehensive support for parsing and validating MATCH_RECOGNIZE
> queries (see CALCITE-1570 and sub-tasks) but we cannot execute them. I know
> the purpose of this work is to do CEP within Flink, but a reference
> implementation that works on non-streaming data would be valuable.
> I propose that we add a class EnumerableMatch that can generate Java code to
> evaluate MATCH_RECOGNIZE queries on Enumerable data. It does not need to be
> efficient. I don't mind if it (say) buffers all the data in memory and makes
> O(n ^ 3) passes over it. People can make it more efficient over time.
> When we have a reference implementation, people can start playing with this
> feature. And we can start building a corpus of data sets, queries, and their
> expected result. The Flink implementation will be able to test against those
> same queries, and should give the same results, even though Flink will be
> reading streaming data.
> Let's create {{match.iq}} with the following query based on
> https://oracle-base.com/articles/12c/pattern-matching-in-oracle-database-12cr1:
> {code}
> !set outputformat mysql
> !use match
> SELECT *
> FROM sales_history MATCH_RECOGNIZE (
> PARTITION BY product
> ORDER BY tstamp
> MEASURES STRT.tstamp AS start_tstamp,
>LAST(UP.tstamp) AS peak_tstamp,
>LAST(DOWN.tstamp) AS end_tstamp,
>MATCH_NUMBER() AS mno
> ONE ROW PER MATCH
> AFTER MATCH SKIP TO LAST DOWN
> PATTERN (STRT UP+ FLAT* DOWN+)
> DEFINE
>UP AS UP.units_sold > PREV(UP.units_sold),
>FLAT AS FLAT.units_sold = PREV(FLAT.units_sold),
>DOWN AS DOWN.units_sold < PREV(DOWN.units_sold)
>) MR
> ORDER BY MR.product, MR.start_tstamp;
> PRODUCTSTART_TSTAM PEAK_TSTAMP END_TSTAMP MNO
> -- --- --- --- --
> TWINKIES 01-OCT-2014 03-OCT-2014 06-OCT-2014 1
> TWINKIES 06-OCT-2014 08-OCT-2014 09-OCT-2014 2
> TWINKIES 09-OCT-2014 13-OCT-2014 16-OCT-2014 3
> TWINKIES 16-OCT-2014 18-OCT-2014 20-OCT-2014 4
> 4 rows selected.
> !ok
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1938) First Apache release for Avatica Go
[ https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125127#comment-16125127 ] Josh Elser commented on CALCITE-1938: - bq. The tests are integration tests, so you'd need to have an instance of Phoenix and PQS available Ok.. the README needs to be updated then. It's a bit misleading at this point. Do you have any "traditional" unit tests on the horizon? How much work do you think it would be to use https://hub.docker.com/r/apache/calcite-avatica/ instead (avatica + hsqldb)? Reducing the scope of what is required to run tests would be great. > First Apache release for Avatica Go > --- > > Key: CALCITE-1938 > URL: https://issues.apache.org/jira/browse/CALCITE-1938 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Reporter: Julian Hyde >Assignee: Francis Chuang > > Make a release for Avatica Go. > Release number is TBD. > This will be the first Apache release for Avacica Go, so expect more > diligence / issues than usual. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1938) First Apache release for Avatica Go
[ https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125117#comment-16125117 ] Francis Chuang commented on CALCITE-1938: - [~elserj] The tests are integration test, so you'd need to have an instance of phoenix and PQS available. In my tests, I use my HBase-Phoenix docker image with transactions and PSQ enabled: https://github.com/Boostport/hbase-phoenix-all-in-one Once this is done, you need to set the AVATICA_HOST environment variable to point to PQS. The tests do take a while to run (because creating and deleting schemas and tables can be a bit slow), but if the PQS is not available after 5 minutes, the tests should timeout and fail. You can check out how the tests are set up and executed on Wercker here: https://github.com/apache/calcite-avatica-go/blob/master/wercker.yml > First Apache release for Avatica Go > --- > > Key: CALCITE-1938 > URL: https://issues.apache.org/jira/browse/CALCITE-1938 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Reporter: Julian Hyde >Assignee: Francis Chuang > > Make a release for Avatica Go. > Release number is TBD. > This will be the first Apache release for Avacica Go, so expect more > diligence / issues than usual. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1938) First Apache release for Avatica Go
[ https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125117#comment-16125117 ] Francis Chuang edited comment on CALCITE-1938 at 8/14/17 1:15 AM: -- [~elserj] The tests are integration tests, so you'd need to have an instance of Phoenix and PQS available. In my tests, I use my HBase-Phoenix docker image with transactions and PSQ enabled: https://github.com/Boostport/hbase-phoenix-all-in-one Once this is done, you need to set the AVATICA_HOST environment variable to point to PQS. The tests do take a while to run (because creating and deleting schemas and tables can be a bit slow), but if the PQS is not available after 5 minutes, the tests should timeout and fail. You can check out how the tests are set up and executed on Wercker here: https://github.com/apache/calcite-avatica-go/blob/master/wercker.yml was (Author: francischuang): [~elserj] The tests are integration test, so you'd need to have an instance of phoenix and PQS available. In my tests, I use my HBase-Phoenix docker image with transactions and PSQ enabled: https://github.com/Boostport/hbase-phoenix-all-in-one Once this is done, you need to set the AVATICA_HOST environment variable to point to PQS. The tests do take a while to run (because creating and deleting schemas and tables can be a bit slow), but if the PQS is not available after 5 minutes, the tests should timeout and fail. You can check out how the tests are set up and executed on Wercker here: https://github.com/apache/calcite-avatica-go/blob/master/wercker.yml > First Apache release for Avatica Go > --- > > Key: CALCITE-1938 > URL: https://issues.apache.org/jira/browse/CALCITE-1938 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Reporter: Julian Hyde >Assignee: Francis Chuang > > Make a release for Avatica Go. > Release number is TBD. > This will be the first Apache release for Avacica Go, so expect more > diligence / issues than usual. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1938) First Apache release for Avatica Go
[
https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125103#comment-16125103
]
Josh Elser commented on CALCITE-1938:
-
{noformat}
$ mkdir -p ~/go/src/github.com/apache
$ git clone https://git-wip-us.apache.org/repos/asf/calcite-avatica-go.git
$ cd calcite-avatica-go
$ dep ensure
$ go test $(go list ./... | grep -v vendor)
{noformat}
The {{go test}} command just seems to hang and not do anything. I can't seem to
find any sort of option for more verbosity either. Thoughts, [~francischuang]?
> First Apache release for Avatica Go
> ---
>
> Key: CALCITE-1938
> URL: https://issues.apache.org/jira/browse/CALCITE-1938
> Project: Calcite
> Issue Type: Bug
> Components: avatica-go
>Reporter: Julian Hyde
>Assignee: Francis Chuang
>
> Make a release for Avatica Go.
> Release number is TBD.
> This will be the first Apache release for Avacica Go, so expect more
> diligence / issues than usual.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1903) Support charset in LIKE expression
[
https://issues.apache.org/jira/browse/CALCITE-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112234#comment-16112234
]
Ted Yu edited comment on CALCITE-1903 at 8/13/17 2:13 PM:
--
Letting validator detect this problem is good choice.
was (Author: yuzhih...@gmail.com):
Letting validator detect this problem is good.
> Support charset in LIKE expression
> --
>
> Key: CALCITE-1903
> URL: https://issues.apache.org/jira/browse/CALCITE-1903
> Project: Calcite
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Julian Hyde
>
> From
> http://search-hadoop.com/m/Flink/VkLeQbjp59T6PkF?subj=+How+can+I+set+charset+for+flink+sql+
> The following query
> {code}
> SELECT
> 'HIGH' AS LEVEL,
> 'Firewall uplink bandwidth exception:greater than 1' AS content,
> `system.process.username`,
> `system.process.memory.rss.bytes`
> FROM
> test
> WHERE
> `system.process.username` LIKE '%高危%'
> {code}
> produces the following:
> {code}
> Caused by: org.apache.calcite.runtime.CalciteException: Failed to encode
> '%高危%' in character set 'ISO-8859-1'
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method) ~[na:1.8.0_45]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
> Source) ~[na:1.8.0_45]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
> Source) ~[na:1.8.0_45]
> at java.lang.reflect.Constructor.newInstance(Unknown Source)
> ~[na:1.8.0_45]
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:572)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at org.apache.calcite.util.NlsString.(NlsString.java:81)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:864)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.rex.RexBuilder.makeCharLiteral(RexBuilder.java:1051)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertLiteral(SqlNodeToRexConverterImpl.java:117)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4408)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3787)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at org.apache.calcite.sql.SqlLiteral.accept(SqlLiteral.java:427)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4321)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.convertExpressionList(StandardConvertletTable.java:968)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.convertCall(StandardConvertletTable.java:944)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.convertCall(StandardConvertletTable.java:928)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> ... 50 common frames omitted
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
