[jira] [Created] (CALCITE-1192) Document protobuf and json REP types with examples
Francis Chuang created CALCITE-1192: --- Summary: Document protobuf and json REP types with examples Key: CALCITE-1192 URL: https://issues.apache.org/jira/browse/CALCITE-1192 Project: Calcite Issue Type: Improvement Components: avatica Reporter: Francis Chuang It would be nice to have the documentation for the Rep types here (https://calcite.apache.org/docs/avatica_protobuf_reference.html#rep) documented with examples to show what the serialized representation looks like. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1198) Wrong rep type returned for date, time and timestamps in column metadata
[
https://issues.apache.org/jira/browse/CALCITE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15238634#comment-15238634
]
Francis Chuang commented on CALCITE-1198:
-
Found the answer to my question in this piece of code:
https://github.com/apache/calcite/blob/master/avatica/core/src/main/java/org/apache/calcite/avatica/remote/TypedValue.java#L112
> Wrong rep type returned for date, time and timestamps in column metadata
>
>
> Key: CALCITE-1198
> URL: https://issues.apache.org/jira/browse/CALCITE-1198
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.7.1
> Environment: Phoenix 4.7.0
>Reporter: Francis Chuang
>
> To reproduce the problem:
> 1. Create a table containing date, time and timestamp columns using
> SquirrelSQL or similiar:
> {code}
> CREATE TABLE test (id INTEGER PRIMARY KEY, tm TIME,dt DATE,tmstmp TIMESTAMP)
> TRANSACTIONAL=false
> {code}
> 2. Use curl to query the phoenix query server/avatica:
> {code}
> curl localhost:8765 -XPOST --data '{"request":
> "openConnection","connectionId": "my-conn"}'
> curl localhost:8765 -XPOST --data '{"request": "prepare","connectionId":
> "my-conn","sql": "SELECT * FROM test","maxRowCount": 1}'
> {code}
> This is the result of the prepare request:
> {code}
> {
> "response": "prepare",
> "statement": {
> "connectionId": "my-conn",
> "id": 27,
> "signature": {
> "columns": [
> {
> "ordinal": 0,
> "autoIncrement": false,
> "caseSensitive": false,
> "searchable": true,
> "currency": false,
> "nullable": 0,
> "signed": true,
> "displaySize": 40,
> "label": "ID",
> "columnName": "ID",
> "schemaName": "",
> "precision": 0,
> "scale": 0,
> "tableName": "TEST",
> "catalogName": "",
> "type": {
> "type": "scalar",
> "id": 4,
> "name": "INTEGER",
> "rep": "PRIMITIVE_INT"
> },
> "readOnly": true,
> "writable": false,
> "definitelyWritable": false,
> "columnClassName": "java.lang.Integer"
> },
> {
> "ordinal": 1,
> "autoIncrement": false,
> "caseSensitive": false,
> "searchable": true,
> "currency": false,
> "nullable": 1,
> "signed": false,
> "displaySize": 23,
> "label": "TM",
> "columnName": "TM",
> "schemaName": "",
> "precision": 0,
> "scale": 0,
> "tableName": "TEST",
> "catalogName": "",
> "type": {
> "type": "scalar",
> "id": 92,
> "name": "TIME",
> "rep": "PRIMITIVE_INT"
> },
> "readOnly": true,
> "writable": false,
> "definitelyWritable": false,
> "columnClassName": "java.sql.Time"
> },
> {
> "ordinal": 2,
> "autoIncrement": false,
> "caseSensitive": false,
> "searchable": true,
> "currency": false,
> "nullable": 1,
> "signed": false,
> "displaySize": 23,
> "label": "DT",
> "columnName": "DT",
> "schemaName": "",
> "precision": 0,
> "scale": 0,
> "tableName": "TEST",
> "catalogName": "",
> "type": {
> "type": "scalar",
> "id": 91,
> "name": "DATE",
> "rep": "PRIMITIVE_INT"
> },
> "readOnly": true,
> "writable": false,
> "definitelyWritable": false,
> "columnClassName": "java.sql.Date"
> },
> {
> "ordinal": 3,
> "autoIncrement": false,
> "caseSensitive": false,
> "searchable": true,
> "currency": false,
> "nullable": 1,
> "signed": false,
> "displaySize": 40,
> "label": "TMSTMP",
> "columnName": "TMSTMP",
> "schemaName": "",
> "precision": 0,
> "scale": 0,
> "tableName": "TEST",
> "catalogName": "",
>
[jira] [Created] (CALCITE-1197) Support execute requests without parameters
Francis Chuang created CALCITE-1197:
---
Summary: Support execute requests without parameters
Key: CALCITE-1197
URL: https://issues.apache.org/jira/browse/CALCITE-1197
Project: Calcite
Issue Type: Improvement
Components: avatica
Affects Versions: avatica-1.7.1
Reporter: Francis Chuang
Priority: Minor
If we execute a prepared statement without the {{parameterValues}} key, the
server returns a NullPointerException:
{code}
C:\Users\user
λ curl localhost:8765 -XPOST --data '{
"request": "execute",
"statementHandle": {
"connectionId": "my-conn",
"id": 25,
"signature": {
"columns": [
{
"ordinal": 0,
"autoIncrement": false,
"caseSensitive": false,
"searchable": true,
"currency": false,
"nullable": 0,
"signed": true,
"displaySize": 40,
"label": "K",
"columnName": "K",
"schemaName": "",
"precision": 0,
"scale": 0,
"tableName": "MY_TABLE",
"catalogName": "",
"type": {
"type": "scalar",
"id": -5,
"name": "BIGINT",
"rep": "PRIMITIVE_LONG"
},
"readOnly": true,
"writable": false,
"definitelyWritable": false,
"columnClassName": "java.lang.Long"
},
{
"ordinal": 1,
"autoIncrement": false,
"caseSensitive": false,
"searchable": true,
"currency": false,
"nullable": 1,
"signed": false,
"displaySize": 40,
"label": "V",
"columnName": "V",
"schemaName": "",
"precision": 0,
"scale": 0,
"tableName": "MY_TABLE",
"catalogName": "",
"type": {
"type": "scalar",
"id": 12,
"name": "VARCHAR",
"rep": "STRING"
},
"readOnly": true,
"writable": false,
"definitelyWritable": false,
"columnClassName": "java.lang.String"
}
],
"sql": "SELECT * FROM my_table",
"parameters": [],
"cursorFactory": {
"style": "LIST",
"clazz": null,
"fieldNames": null
},
"statementType": null
}
},
"maxRowCount": 1
}'
{
"response": "error",
"exceptions": [
"java.lang.NullPointerException\n\tat
org.apache.calcite.avatica.jdbc.JdbcMeta.execute(JdbcMeta.java:806)\n\tat
org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:233)\n\tat
org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:950)\n\tat
org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:928)\n\tat
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:102)\n\tat
org.apache.calcite.avatica.remote.JsonHandler.apply(JsonHandler.java:43)\n\tat
org.apache.calcite.avatica.server.AvaticaJsonHandler.handle(AvaticaJsonHandler.java:73)\n\tat
org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)\n\tat
org.eclipse.jetty.server.Server.handle(Server.java:497)\n\tat
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)\n\tat
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:245)\n\tat
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)\n\tat
java.lang.Thread.run(Thread.java:745)\n"
],
"errorMessage": "NullPointerException: (null exception message)",
"errorCode": -1,
"sqlState": "0",
"severity": "UNKNOWN",
"rpcMetadata": {
"response": "rpcMetadata",
"serverAddress": "f826338-phoenix-server.f826338:8765"
}
}
{code}
The workaround is to always ensure that {{parameterValues: []}} is always
included.
However, it would improve the UX if {{parameterValues}} is actually optional as
per the documentation:
https://calcite.apache.org/docs/avatica_protobuf_reference.html#executerequest
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1198) Wrong rep type returned for date, time and timestamps in column metadata
Francis Chuang created CALCITE-1198:
---
Summary: Wrong rep type returned for date, time and timestamps in
column metadata
Key: CALCITE-1198
URL: https://issues.apache.org/jira/browse/CALCITE-1198
Project: Calcite
Issue Type: Improvement
Components: avatica
Affects Versions: avatica-1.7.1
Environment: Phoenix 4.7.0
Reporter: Francis Chuang
To reproduce the problem:
1. Create a table containing date, time and timestamp columns using SquirrelSQL
or similiar:
{code}
CREATE TABLE test (id INTEGER PRIMARY KEY, tm TIME,dt DATE,tmstmp TIMESTAMP)
TRANSACTIONAL=false
{code}
2. Use curl to query the phoenix query server/avatica:
{code}
curl localhost:8765 -XPOST --data '{"request": "openConnection","connectionId":
"my-conn"}'
curl localhost:8765 -XPOST --data '{"request": "prepare","connectionId":
"my-conn","sql": "SELECT * FROM test","maxRowCount": 1}'
{code}
This is the result of the prepare request:
{code}
{
"response": "prepare",
"statement": {
"connectionId": "my-conn",
"id": 27,
"signature": {
"columns": [
{
"ordinal": 0,
"autoIncrement": false,
"caseSensitive": false,
"searchable": true,
"currency": false,
"nullable": 0,
"signed": true,
"displaySize": 40,
"label": "ID",
"columnName": "ID",
"schemaName": "",
"precision": 0,
"scale": 0,
"tableName": "TEST",
"catalogName": "",
"type": {
"type": "scalar",
"id": 4,
"name": "INTEGER",
"rep": "PRIMITIVE_INT"
},
"readOnly": true,
"writable": false,
"definitelyWritable": false,
"columnClassName": "java.lang.Integer"
},
{
"ordinal": 1,
"autoIncrement": false,
"caseSensitive": false,
"searchable": true,
"currency": false,
"nullable": 1,
"signed": false,
"displaySize": 23,
"label": "TM",
"columnName": "TM",
"schemaName": "",
"precision": 0,
"scale": 0,
"tableName": "TEST",
"catalogName": "",
"type": {
"type": "scalar",
"id": 92,
"name": "TIME",
"rep": "PRIMITIVE_INT"
},
"readOnly": true,
"writable": false,
"definitelyWritable": false,
"columnClassName": "java.sql.Time"
},
{
"ordinal": 2,
"autoIncrement": false,
"caseSensitive": false,
"searchable": true,
"currency": false,
"nullable": 1,
"signed": false,
"displaySize": 23,
"label": "DT",
"columnName": "DT",
"schemaName": "",
"precision": 0,
"scale": 0,
"tableName": "TEST",
"catalogName": "",
"type": {
"type": "scalar",
"id": 91,
"name": "DATE",
"rep": "PRIMITIVE_INT"
},
"readOnly": true,
"writable": false,
"definitelyWritable": false,
"columnClassName": "java.sql.Date"
},
{
"ordinal": 3,
"autoIncrement": false,
"caseSensitive": false,
"searchable": true,
"currency": false,
"nullable": 1,
"signed": false,
"displaySize": 40,
"label": "TMSTMP",
"columnName": "TMSTMP",
"schemaName": "",
"precision": 0,
"scale": 0,
"tableName": "TEST",
"catalogName": "",
"type": {
"type": "scalar",
"id": 93,
"name": "TIMESTAMP",
"rep": "PRIMITIVE_LONG"
},
"readOnly": true,
"writable": false,
"definitelyWritable": false,
"columnClassName": "java.sql.Timestamp"
}
],
"sql": "SELECT * FROM test",
"parameters": [],
"cursorFactory": {
"style": "LIST",
"clazz": null,
"fieldNames": null
},
"statementType": null
}
},
"rpcMetadata": {
"response":
[jira] [Commented] (CALCITE-1193) NullPointerException when trying to execute prepared statement using avatica
[
https://issues.apache.org/jira/browse/CALCITE-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15238167#comment-15238167
]
Francis Chuang commented on CALCITE-1193:
-
Unfortunately my knowledge of the Java language and its syntax is extremely
limited, so I will leave it to more capable hands. In the meantime, do you want
me to open separate JIRAs for these 2 points?
> NullPointerException when trying to execute prepared statement using avatica
>
>
> Key: CALCITE-1193
> URL: https://issues.apache.org/jira/browse/CALCITE-1193
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.7.1
> Environment: Phoenix 4.7.0 and Phoenix 4.8.0-SNAPSHOT
>Reporter: Francis Chuang
>Assignee: Josh Elser
>
> To reproduce, set the phoenix query server to use JSON for serialization:
> 1. Create a table called {{my_table}} and seed it using SquirrelSQL:
> {code}
> CREATE TABLE my_table (k BIGINT PRIMARY KEY, v VARCHAR) TRANSACTIONAL=true
> UPSERT INTO my_table VALUES (1,'A')
> UPSERT INTO my_table VALUES (2,'B')
> UPSERT INTO my_table VALUES (3,'C')
> UPSERT INTO my_table VALUES (4,'D')
> {code}
> Send the following requests using curl:
> {code}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request":
> "openConnection","connectionId": "my-conn"}'
> {"response":"openConnection","rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request": "prepare","connectionId":
> "my-conn","sql": "SELECT * FROM my_table","maxRowCount": 1}'
> {"response":"prepare","statement":{"connectionId":"my-conn","id":36,"signature":{"columns":[{"ordinal":0,"autoIncrement":false,"caseSensitive":false,"searchable":true,"currency":false,"nullable":0,"signed":true,"displaySize":40,"label":"K","columnName":"K","schemaName":"","precision":0,"scale":0,"tableName":"MY_TABLE","catalogName":"","type":{"type":"scalar","id":-5,"name":"BIGINT","rep":"PRIMITIVE_LONG"},"readOnly":true,"writable":false,"definitelyWritable":false,"columnClassName":"java.lang.Long"},{"ordinal":1,"autoIncrement":false,"caseSensitive":false,"searchable":true,"currency":false,"nullable":1,"signed":false,"displaySize":40,"label":"V","columnName":"V","schemaName":"","precision":0,"scale":0,"tableName":"MY_TABLE","catalogName":"","type":{"type":"scalar","id":12,"name":"VARCHAR","rep":"STRING"},"readOnly":true,"writable":false,"definitelyWritable":false,"columnClassName":"java.lang.String"}],"sql":"SELECT
> * FROM
> my_table","parameters":[],"cursorFactory":{"style":"LIST","clazz":null,"fieldNames":null},"statementType":null}},"rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request": "execute","statementHandle":
> {"connectionId": "my-conn","id": 36},"maxRowCount": 1}'
> {"response":"error","exceptions":["java.lang.NullPointerException\n\tat
> org.apache.calcite.avatica.MetaImpl.checkParameterValueHasNull(MetaImpl.java:952)\n\tat
> org.apache.calcite.avatica.jdbc.JdbcMeta.execute(JdbcMeta.java:781)\n\tat
> org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:233)\n\tat
>
> org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:950)\n\tat
>
> org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:928)\n\tat
>
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:102)\n\tat
>
> org.apache.calcite.avatica.remote.JsonHandler.apply(JsonHandler.java:43)\n\tat
>
> org.apache.calcite.avatica.server.AvaticaJsonHandler.handle(AvaticaJsonHandler.java:73)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:497)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:245)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)\n\tat
>
> java.lang.Thread.run(Thread.java:745)\n"],"errorMessage":"NullPointerException:
> (null exception
> message)","errorCode":-1,"sqlState":"0","severity":"UNKNOWN","rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
> {code}
> Notice that the server throws a NPE when trying to execute the prepared
> statement.
--
This message was sent
[jira] [Created] (CALCITE-1196) Cache statement handle signatures for prepared statements so that the client won't have to send them during execution
Francis Chuang created CALCITE-1196:
---
Summary: Cache statement handle signatures for prepared statements
so that the client won't have to send them during execution
Key: CALCITE-1196
URL: https://issues.apache.org/jira/browse/CALCITE-1196
Project: Calcite
Issue Type: Improvement
Components: avatica
Affects Versions: avatica-1.7.1
Reporter: Francis Chuang
Priority: Minor
With avatica 1.7.1, to prepare and execute a statement, we need to do the
following (shown using curl):
{code}
C:\Users\user
λ curl localhost:8765 -XPOST --data '{"request": "prepare","connectionId":
"my-conn","sql": "SELECT * FROM my_table","maxRowCount": 1}'
{
"response": "prepare",
"statement": {
"connectionId": "my-conn",
"id": 25,
"signature": {
"columns": [
{
"ordinal": 0,
"autoIncrement": false,
"caseSensitive": false,
"searchable": true,
"currency": false,
"nullable": 0,
"signed": true,
"displaySize": 40,
"label": "K",
"columnName": "K",
"schemaName": "",
"precision": 0,
"scale": 0,
"tableName": "MY_TABLE",
"catalogName": "",
"type": {
"type": "scalar",
"id": -5,
"name": "BIGINT",
"rep": "PRIMITIVE_LONG"
},
"readOnly": true,
"writable": false,
"definitelyWritable": false,
"columnClassName": "java.lang.Long"
},
{
"ordinal": 1,
"autoIncrement": false,
"caseSensitive": false,
"searchable": true,
"currency": false,
"nullable": 1,
"signed": false,
"displaySize": 40,
"label": "V",
"columnName": "V",
"schemaName": "",
"precision": 0,
"scale": 0,
"tableName": "MY_TABLE",
"catalogName": "",
"type": {
"type": "scalar",
"id": 12,
"name": "VARCHAR",
"rep": "STRING"
},
"readOnly": true,
"writable": false,
"definitelyWritable": false,
"columnClassName": "java.lang.String"
}
],
"sql": "SELECT * FROM my_table",
"parameters": [],
"cursorFactory": {
"style": "LIST",
"clazz": null,
"fieldNames": null
},
"statementType": null
}
},
"rpcMetadata": {
"response": "rpcMetadata",
"serverAddress": "f826338-phoenix-server.f826338:8765"
}
}
C:\Users\user
λ curl localhost:8765 -XPOST --data '{
"request": "execute",
"statementHandle": {
"connectionId": "my-conn",
"id": 25,
"signature": {
"columns": [
{
"ordinal": 0,
"autoIncrement": false,
"caseSensitive": false,
"searchable": true,
"currency": false,
"nullable": 0,
"signed": true,
"displaySize": 40,
"label": "K",
"columnName": "K",
"schemaName": "",
"precision": 0,
"scale": 0,
"tableName": "MY_TABLE",
"catalogName": "",
"type": {
"type": "scalar",
"id": -5,
"name": "BIGINT",
"rep": "PRIMITIVE_LONG"
},
"readOnly": true,
"writable": false,
"definitelyWritable": false,
"columnClassName": "java.lang.Long"
},
{
"ordinal": 1,
"autoIncrement": false,
"caseSensitive": false,
"searchable": true,
"currency": false,
"nullable": 1,
"signed": false,
"displaySize": 40,
"label": "V",
"columnName": "V",
"schemaName": "",
"precision": 0,
"scale": 0,
"tableName": "MY_TABLE",
"catalogName": "",
"type": {
"type": "scalar",
"id": 12,
"name": "VARCHAR",
"rep": "STRING"
},
"readOnly": true,
"writable": false,
"definitelyWritable": false,
"columnClassName": "java.lang.String"
}
],
[jira] [Updated] (CALCITE-1198) Wrong rep type returned for date, time and timestamps in column metadata
[
https://issues.apache.org/jira/browse/CALCITE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis Chuang updated CALCITE-1198:
Description:
To reproduce the problem:
1. Create a table containing date, time and timestamp columns using SquirrelSQL
or similiar:
{code}
CREATE TABLE test (id INTEGER PRIMARY KEY, tm TIME,dt DATE,tmstmp TIMESTAMP)
TRANSACTIONAL=false
{code}
2. Use curl to query the phoenix query server/avatica:
{code}
curl localhost:8765 -XPOST --data '{"request": "openConnection","connectionId":
"my-conn"}'
curl localhost:8765 -XPOST --data '{"request": "prepare","connectionId":
"my-conn","sql": "SELECT * FROM test","maxRowCount": 1}'
{code}
This is the result of the prepare request:
{code}
{
"response": "prepare",
"statement": {
"connectionId": "my-conn",
"id": 27,
"signature": {
"columns": [
{
"ordinal": 0,
"autoIncrement": false,
"caseSensitive": false,
"searchable": true,
"currency": false,
"nullable": 0,
"signed": true,
"displaySize": 40,
"label": "ID",
"columnName": "ID",
"schemaName": "",
"precision": 0,
"scale": 0,
"tableName": "TEST",
"catalogName": "",
"type": {
"type": "scalar",
"id": 4,
"name": "INTEGER",
"rep": "PRIMITIVE_INT"
},
"readOnly": true,
"writable": false,
"definitelyWritable": false,
"columnClassName": "java.lang.Integer"
},
{
"ordinal": 1,
"autoIncrement": false,
"caseSensitive": false,
"searchable": true,
"currency": false,
"nullable": 1,
"signed": false,
"displaySize": 23,
"label": "TM",
"columnName": "TM",
"schemaName": "",
"precision": 0,
"scale": 0,
"tableName": "TEST",
"catalogName": "",
"type": {
"type": "scalar",
"id": 92,
"name": "TIME",
"rep": "PRIMITIVE_INT"
},
"readOnly": true,
"writable": false,
"definitelyWritable": false,
"columnClassName": "java.sql.Time"
},
{
"ordinal": 2,
"autoIncrement": false,
"caseSensitive": false,
"searchable": true,
"currency": false,
"nullable": 1,
"signed": false,
"displaySize": 23,
"label": "DT",
"columnName": "DT",
"schemaName": "",
"precision": 0,
"scale": 0,
"tableName": "TEST",
"catalogName": "",
"type": {
"type": "scalar",
"id": 91,
"name": "DATE",
"rep": "PRIMITIVE_INT"
},
"readOnly": true,
"writable": false,
"definitelyWritable": false,
"columnClassName": "java.sql.Date"
},
{
"ordinal": 3,
"autoIncrement": false,
"caseSensitive": false,
"searchable": true,
"currency": false,
"nullable": 1,
"signed": false,
"displaySize": 40,
"label": "TMSTMP",
"columnName": "TMSTMP",
"schemaName": "",
"precision": 0,
"scale": 0,
"tableName": "TEST",
"catalogName": "",
"type": {
"type": "scalar",
"id": 93,
"name": "TIMESTAMP",
"rep": "PRIMITIVE_LONG"
},
"readOnly": true,
"writable": false,
"definitelyWritable": false,
"columnClassName": "java.sql.Timestamp"
}
],
"sql": "SELECT * FROM test",
"parameters": [],
"cursorFactory": {
"style": "LIST",
"clazz": null,
"fieldNames": null
},
"statementType": null
}
},
"rpcMetadata": {
"response": "rpcMetadata",
"serverAddress": "f826338-phoenix-server.f826338:8765"
}
}
{code}
In the results, {{time}} and {{date}} has a rep of {{PRIMITIVE_INT}} and
{{timestamp}} has a rep type of {{PRIMITIVE_LONG}}. I believe they should have
rep types of
[jira] [Commented] (CALCITE-1198) Wrong rep type returned for date, time and timestamps in column metadata
[
https://issues.apache.org/jira/browse/CALCITE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15238587#comment-15238587
]
Francis Chuang commented on CALCITE-1198:
-
Ah, I see! That makes sense.
How do I unserialize the date and time?
If I have time and date inserted as '2016-04-13 02:13:15', '2016-04-13
02:13:15'.
They are coming back (via avatica) as 2 ints: 7995000, 16904
> Wrong rep type returned for date, time and timestamps in column metadata
>
>
> Key: CALCITE-1198
> URL: https://issues.apache.org/jira/browse/CALCITE-1198
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.7.1
> Environment: Phoenix 4.7.0
>Reporter: Francis Chuang
>
> To reproduce the problem:
> 1. Create a table containing date, time and timestamp columns using
> SquirrelSQL or similiar:
> {code}
> CREATE TABLE test (id INTEGER PRIMARY KEY, tm TIME,dt DATE,tmstmp TIMESTAMP)
> TRANSACTIONAL=false
> {code}
> 2. Use curl to query the phoenix query server/avatica:
> {code}
> curl localhost:8765 -XPOST --data '{"request":
> "openConnection","connectionId": "my-conn"}'
> curl localhost:8765 -XPOST --data '{"request": "prepare","connectionId":
> "my-conn","sql": "SELECT * FROM test","maxRowCount": 1}'
> {code}
> This is the result of the prepare request:
> {code}
> {
> "response": "prepare",
> "statement": {
> "connectionId": "my-conn",
> "id": 27,
> "signature": {
> "columns": [
> {
> "ordinal": 0,
> "autoIncrement": false,
> "caseSensitive": false,
> "searchable": true,
> "currency": false,
> "nullable": 0,
> "signed": true,
> "displaySize": 40,
> "label": "ID",
> "columnName": "ID",
> "schemaName": "",
> "precision": 0,
> "scale": 0,
> "tableName": "TEST",
> "catalogName": "",
> "type": {
> "type": "scalar",
> "id": 4,
> "name": "INTEGER",
> "rep": "PRIMITIVE_INT"
> },
> "readOnly": true,
> "writable": false,
> "definitelyWritable": false,
> "columnClassName": "java.lang.Integer"
> },
> {
> "ordinal": 1,
> "autoIncrement": false,
> "caseSensitive": false,
> "searchable": true,
> "currency": false,
> "nullable": 1,
> "signed": false,
> "displaySize": 23,
> "label": "TM",
> "columnName": "TM",
> "schemaName": "",
> "precision": 0,
> "scale": 0,
> "tableName": "TEST",
> "catalogName": "",
> "type": {
> "type": "scalar",
> "id": 92,
> "name": "TIME",
> "rep": "PRIMITIVE_INT"
> },
> "readOnly": true,
> "writable": false,
> "definitelyWritable": false,
> "columnClassName": "java.sql.Time"
> },
> {
> "ordinal": 2,
> "autoIncrement": false,
> "caseSensitive": false,
> "searchable": true,
> "currency": false,
> "nullable": 1,
> "signed": false,
> "displaySize": 23,
> "label": "DT",
> "columnName": "DT",
> "schemaName": "",
> "precision": 0,
> "scale": 0,
> "tableName": "TEST",
> "catalogName": "",
> "type": {
> "type": "scalar",
> "id": 91,
> "name": "DATE",
> "rep": "PRIMITIVE_INT"
> },
> "readOnly": true,
> "writable": false,
> "definitelyWritable": false,
> "columnClassName": "java.sql.Date"
> },
> {
> "ordinal": 3,
> "autoIncrement": false,
> "caseSensitive": false,
> "searchable": true,
> "currency": false,
> "nullable": 1,
> "signed": false,
> "displaySize": 40,
> "label": "TMSTMP",
> "columnName": "TMSTMP",
> "schemaName": "",
> "precision": 0,
> "scale": 0,
> "tableName": "TEST",
>
[jira] [Commented] (CALCITE-1193) NullPointerException when trying to execute prepared statement using avatica
[
https://issues.apache.org/jira/browse/CALCITE-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15234383#comment-15234383
]
Francis Chuang commented on CALCITE-1193:
-
[~elserj]Any chance this can be expedited? I have pretty much written all the
code for my golang avatica/phoenix driver, but am unable open source it yet
because I am can't run any of my tests against a real phoenix query server due
to this issue.
> NullPointerException when trying to execute prepared statement using avatica
>
>
> Key: CALCITE-1193
> URL: https://issues.apache.org/jira/browse/CALCITE-1193
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.7.1
> Environment: Phoenix 4.7.0 and Phoenix 4.8.0-SNAPSHOT
>Reporter: Francis Chuang
>Assignee: Josh Elser
>
> To reproduce, set the phoenix query server to use JSON for serialization:
> 1. Create a table called {{my_table}} and seed it using SquirrelSQL:
> {code}
> CREATE TABLE my_table (k BIGINT PRIMARY KEY, v VARCHAR) TRANSACTIONAL=true
> UPSERT INTO my_table VALUES (1,'A')
> UPSERT INTO my_table VALUES (2,'B')
> UPSERT INTO my_table VALUES (3,'C')
> UPSERT INTO my_table VALUES (4,'D')
> {code}
> Send the following requests using curl:
> {code}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request":
> "openConnection","connectionId": "my-conn"}'
> {"response":"openConnection","rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request": "prepare","connectionId":
> "my-conn","sql": "SELECT * FROM my_table","maxRowCount": 1}'
> {"response":"prepare","statement":{"connectionId":"my-conn","id":36,"signature":{"columns":[{"ordinal":0,"autoIncrement":false,"caseSensitive":false,"searchable":true,"currency":false,"nullable":0,"signed":true,"displaySize":40,"label":"K","columnName":"K","schemaName":"","precision":0,"scale":0,"tableName":"MY_TABLE","catalogName":"","type":{"type":"scalar","id":-5,"name":"BIGINT","rep":"PRIMITIVE_LONG"},"readOnly":true,"writable":false,"definitelyWritable":false,"columnClassName":"java.lang.Long"},{"ordinal":1,"autoIncrement":false,"caseSensitive":false,"searchable":true,"currency":false,"nullable":1,"signed":false,"displaySize":40,"label":"V","columnName":"V","schemaName":"","precision":0,"scale":0,"tableName":"MY_TABLE","catalogName":"","type":{"type":"scalar","id":12,"name":"VARCHAR","rep":"STRING"},"readOnly":true,"writable":false,"definitelyWritable":false,"columnClassName":"java.lang.String"}],"sql":"SELECT
> * FROM
> my_table","parameters":[],"cursorFactory":{"style":"LIST","clazz":null,"fieldNames":null},"statementType":null}},"rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request": "execute","statementHandle":
> {"connectionId": "my-conn","id": 36},"maxRowCount": 1}'
> {"response":"error","exceptions":["java.lang.NullPointerException\n\tat
> org.apache.calcite.avatica.MetaImpl.checkParameterValueHasNull(MetaImpl.java:952)\n\tat
> org.apache.calcite.avatica.jdbc.JdbcMeta.execute(JdbcMeta.java:781)\n\tat
> org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:233)\n\tat
>
> org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:950)\n\tat
>
> org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:928)\n\tat
>
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:102)\n\tat
>
> org.apache.calcite.avatica.remote.JsonHandler.apply(JsonHandler.java:43)\n\tat
>
> org.apache.calcite.avatica.server.AvaticaJsonHandler.handle(AvaticaJsonHandler.java:73)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:497)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:245)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)\n\tat
>
> java.lang.Thread.run(Thread.java:745)\n"],"errorMessage":"NullPointerException:
> (null exception
> message)","errorCode":-1,"sqlState":"0","severity":"UNKNOWN","rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
> {code}
> Notice that the server throws a NPE when trying to execute the
[jira] [Commented] (CALCITE-1193) NullPointerException when trying to execute prepared statement using avatica
[
https://issues.apache.org/jira/browse/CALCITE-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15234465#comment-15234465
]
Francis Chuang commented on CALCITE-1193:
-
[~elserj] I tried that, but it's also giving me an NPE:
{{code}}
C:\Users\user
λ curl localhost:8765 -XPOST --data '{"request":
"openConnection","connectionId": "my-conn"}'
{"response":"openConnection","rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
C:\Users\user
λ curl localhost:8765 -XPOST --data '{"request": "prepare","connectionId":
"my-conn","sql": "SELECT * FROM my_table","maxRowCount": 1}'
{"response":"prepare","statement":{"connectionId":"my-conn","id":25,"signature":{"columns":[{"ordinal":0,"autoIncrement":false,"caseSensitive":false,"searchable":true,"currency":false,"nullable":0,"signed":true,"displaySize":40,"label":"K","columnName":"K","schemaName":"","precision":0,"scale":0,"tableName":"MY_TABLE","catalogName":"","type":{"type":"scalar","id":-5,"name":"BIGINT","rep":"PRIMITIVE_LONG"},"readOnly":true,"writable":false,"definitelyWritable":false,"columnClassName":"java.lang.Long"},{"ordinal":1,"autoIncrement":false,"caseSensitive":false,"searchable":true,"currency":false,"nullable":1,"signed":false,"displaySize":40,"label":"V","columnName":"V","schemaName":"","precision":0,"scale":0,"tableName":"MY_TABLE","catalogName":"","type":{"type":"scalar","id":12,"name":"VARCHAR","rep":"STRING"},"readOnly":true,"writable":false,"definitelyWritable":false,"columnClassName":"java.lang.String"}],"sql":"SELECT
* FROM
my_table","parameters":[],"cursorFactory":{"style":"LIST","clazz":null,"fieldNames":null},"statementType":null}},"rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
C:\Users\user
λ curl localhost:8765 -XPOST --data '{"request": "execute","statementHandle":
{"connectionId": "my-conn","id": 25}, "parameterValues":[],"maxRowCount": 1}'
{"response":"error","exceptions":["java.lang.NullPointerException\n\tat
org.apache.calcite.avatica.jdbc.JdbcMeta.execute(JdbcMeta.java:806)\n\tat
org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:233)\n\tat
org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:950)\n\tat
org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:928)\n\tat
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:102)\n\tat
org.apache.calcite.avatica.remote.JsonHandler.apply(JsonHandler.java:43)\n\tat
org.apache.calcite.avatica.server.AvaticaJsonHandler.handle(AvaticaJsonHandler.java:73)\n\tat
org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)\n\tat
org.eclipse.jetty.server.Server.handle(Server.java:497)\n\tat
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)\n\tat
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:245)\n\tat
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)\n\tat
java.lang.Thread.run(Thread.java:745)\n"],"errorMessage":"NullPointerException:
(null exception
message)","errorCode":-1,"sqlState":"0","severity":"UNKNOWN","rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
{{code}}
> NullPointerException when trying to execute prepared statement using avatica
>
>
> Key: CALCITE-1193
> URL: https://issues.apache.org/jira/browse/CALCITE-1193
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.7.1
> Environment: Phoenix 4.7.0 and Phoenix 4.8.0-SNAPSHOT
>Reporter: Francis Chuang
>Assignee: Josh Elser
>
> To reproduce, set the phoenix query server to use JSON for serialization:
> 1. Create a table called {{my_table}} and seed it using SquirrelSQL:
> {code}
> CREATE TABLE my_table (k BIGINT PRIMARY KEY, v VARCHAR) TRANSACTIONAL=true
> UPSERT INTO my_table VALUES (1,'A')
> UPSERT INTO my_table VALUES (2,'B')
> UPSERT INTO my_table VALUES (3,'C')
> UPSERT INTO my_table VALUES (4,'D')
> {code}
> Send the following requests using curl:
> {code}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request":
> "openConnection","connectionId": "my-conn"}'
> {"response":"openConnection","rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request": "prepare","connectionId":
> "my-conn","sql": "SELECT * FROM my_table","maxRowCount": 1}'
>
[jira] [Comment Edited] (CALCITE-1193) NullPointerException when trying to execute prepared statement using avatica
[
https://issues.apache.org/jira/browse/CALCITE-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15234465#comment-15234465
]
Francis Chuang edited comment on CALCITE-1193 at 4/11/16 3:57 AM:
--
[~elserj] I tried that, but it's also giving me an NPE:
{code}
C:\Users\user
λ curl localhost:8765 -XPOST --data '{"request":
"openConnection","connectionId": "my-conn"}'
{"response":"openConnection","rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
C:\Users\user
λ curl localhost:8765 -XPOST --data '{"request": "prepare","connectionId":
"my-conn","sql": "SELECT * FROM my_table","maxRowCount": 1}'
{"response":"prepare","statement":{"connectionId":"my-conn","id":25,"signature":{"columns":[{"ordinal":0,"autoIncrement":false,"caseSensitive":false,"searchable":true,"currency":false,"nullable":0,"signed":true,"displaySize":40,"label":"K","columnName":"K","schemaName":"","precision":0,"scale":0,"tableName":"MY_TABLE","catalogName":"","type":{"type":"scalar","id":-5,"name":"BIGINT","rep":"PRIMITIVE_LONG"},"readOnly":true,"writable":false,"definitelyWritable":false,"columnClassName":"java.lang.Long"},{"ordinal":1,"autoIncrement":false,"caseSensitive":false,"searchable":true,"currency":false,"nullable":1,"signed":false,"displaySize":40,"label":"V","columnName":"V","schemaName":"","precision":0,"scale":0,"tableName":"MY_TABLE","catalogName":"","type":{"type":"scalar","id":12,"name":"VARCHAR","rep":"STRING"},"readOnly":true,"writable":false,"definitelyWritable":false,"columnClassName":"java.lang.String"}],"sql":"SELECT
* FROM
my_table","parameters":[],"cursorFactory":{"style":"LIST","clazz":null,"fieldNames":null},"statementType":null}},"rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
C:\Users\user
λ curl localhost:8765 -XPOST --data '{"request": "execute","statementHandle":
{"connectionId": "my-conn","id": 25}, "parameterValues":[],"maxRowCount": 1}'
{"response":"error","exceptions":["java.lang.NullPointerException\n\tat
org.apache.calcite.avatica.jdbc.JdbcMeta.execute(JdbcMeta.java:806)\n\tat
org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:233)\n\tat
org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:950)\n\tat
org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:928)\n\tat
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:102)\n\tat
org.apache.calcite.avatica.remote.JsonHandler.apply(JsonHandler.java:43)\n\tat
org.apache.calcite.avatica.server.AvaticaJsonHandler.handle(AvaticaJsonHandler.java:73)\n\tat
org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)\n\tat
org.eclipse.jetty.server.Server.handle(Server.java:497)\n\tat
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)\n\tat
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:245)\n\tat
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)\n\tat
java.lang.Thread.run(Thread.java:745)\n"],"errorMessage":"NullPointerException:
(null exception
message)","errorCode":-1,"sqlState":"0","severity":"UNKNOWN","rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
{code}
was (Author: francischuang):
[~elserj] I tried that, but it's also giving me an NPE:
{{code}}
C:\Users\user
λ curl localhost:8765 -XPOST --data '{"request":
"openConnection","connectionId": "my-conn"}'
{"response":"openConnection","rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
C:\Users\user
λ curl localhost:8765 -XPOST --data '{"request": "prepare","connectionId":
"my-conn","sql": "SELECT * FROM my_table","maxRowCount": 1}'
[jira] [Comment Edited] (CALCITE-1193) NullPointerException when trying to execute prepared statement using avatica
[
https://issues.apache.org/jira/browse/CALCITE-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15234523#comment-15234523
]
Francis Chuang edited comment on CALCITE-1193 at 4/11/16 6:03 AM:
--
[~elserj]. Here's a simple test case I came up with (hopefully it's valid
Java!). Let me know if it's able to reproduce the problem:
{code}
@Test public void testPreparedStatementWithoutParameters() throws Exception {
ConnectionSpec.getDatabaseLock().lock();
try (Connection conn = getLocalConnection();
Statement stmt = conn.createStatement()) {
assertFalse(stmt.execute("DROP TABLE IF EXISTS test"));
final String sql = "CREATE TABLE test(id integer)";
assertFalse(stmt.execute(sql));
PreparedStatement pstmt = conn.prepareStatement("SELECT * FROM test");
assertTrue(pstmt.execute());
} finally {
ConnectionSpec.getDatabaseLock().unlock();
}
}
{code}
To run, I used: mvn -DfailIfNoTests=false
-Dtest=RemoteDriverTest#testPreparedStatementWithoutParameters
-Dcheckstyle.skip=true -e test
was (Author: francischuang):
[~elserj]. Here's a simple test case I came up with (hopefully it's valid
Java!). Let me know if it's able to reproduce the problem:
{code}
@Test public void testPreparedStatementWithoutParameters() throws Exception {
ConnectionSpec.getDatabaseLock().lock();
try (Connection conn = getLocalConnection();
Statement stmt = conn.createStatement()) {
assertTrue(stmt.execute("DROP TABLE IF EXISTS test"));
final String sql = "CREATE TABLE test(id integer)";
assertTrue(stmt.execute(sql));
PreparedStatement pstmt = conn.prepareStatement("SELECT * FROM test");
assertTrue(pstmt.execute());
} finally {
ConnectionSpec.getDatabaseLock().unlock();
}
}
{code}
To run, I used: mvn -DfailIfNoTests=false
-Dtest=RemoteDriverTest#testPreparedStatementWithoutParameters
-Dcheckstyle.skip=true -e test
> NullPointerException when trying to execute prepared statement using avatica
>
>
> Key: CALCITE-1193
> URL: https://issues.apache.org/jira/browse/CALCITE-1193
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.7.1
> Environment: Phoenix 4.7.0 and Phoenix 4.8.0-SNAPSHOT
>Reporter: Francis Chuang
>Assignee: Josh Elser
>
> To reproduce, set the phoenix query server to use JSON for serialization:
> 1. Create a table called {{my_table}} and seed it using SquirrelSQL:
> {code}
> CREATE TABLE my_table (k BIGINT PRIMARY KEY, v VARCHAR) TRANSACTIONAL=true
> UPSERT INTO my_table VALUES (1,'A')
> UPSERT INTO my_table VALUES (2,'B')
> UPSERT INTO my_table VALUES (3,'C')
> UPSERT INTO my_table VALUES (4,'D')
> {code}
> Send the following requests using curl:
> {code}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request":
> "openConnection","connectionId": "my-conn"}'
> {"response":"openConnection","rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request": "prepare","connectionId":
> "my-conn","sql": "SELECT * FROM my_table","maxRowCount": 1}'
> {"response":"prepare","statement":{"connectionId":"my-conn","id":36,"signature":{"columns":[{"ordinal":0,"autoIncrement":false,"caseSensitive":false,"searchable":true,"currency":false,"nullable":0,"signed":true,"displaySize":40,"label":"K","columnName":"K","schemaName":"","precision":0,"scale":0,"tableName":"MY_TABLE","catalogName":"","type":{"type":"scalar","id":-5,"name":"BIGINT","rep":"PRIMITIVE_LONG"},"readOnly":true,"writable":false,"definitelyWritable":false,"columnClassName":"java.lang.Long"},{"ordinal":1,"autoIncrement":false,"caseSensitive":false,"searchable":true,"currency":false,"nullable":1,"signed":false,"displaySize":40,"label":"V","columnName":"V","schemaName":"","precision":0,"scale":0,"tableName":"MY_TABLE","catalogName":"","type":{"type":"scalar","id":12,"name":"VARCHAR","rep":"STRING"},"readOnly":true,"writable":false,"definitelyWritable":false,"columnClassName":"java.lang.String"}],"sql":"SELECT
> * FROM
> my_table","parameters":[],"cursorFactory":{"style":"LIST","clazz":null,"fieldNames":null},"statementType":null}},"rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request": "execute","statementHandle":
> {"connectionId": "my-conn","id": 36},"maxRowCount": 1}'
> {"response":"error","exceptions":["java.lang.NullPointerException\n\tat
> org.apache.calcite.avatica.MetaImpl.checkParameterValueHasNull(MetaImpl.java:952)\n\tat
> org.apache.calcite.avatica.jdbc.JdbcMeta.execute(JdbcMeta.java:781)\n\tat
>
[jira] [Created] (CALCITE-1191) Support parameter binding for PrepareAndExecute
Francis Chuang created CALCITE-1191: --- Summary: Support parameter binding for PrepareAndExecute Key: CALCITE-1191 URL: https://issues.apache.org/jira/browse/CALCITE-1191 Project: Calcite Issue Type: Improvement Components: avatica Affects Versions: avatica-1.7.1 Reporter: Francis Chuang I am currently working on a golang sql driver for avatica. There are a few implementable interfaces that allows short cutting by preparing and executing a statement in one request. For example, the Execer interface: https://golang.org/pkg/database/sql/driver/#Execer Currently, I am unable to use PrepareAndExecute to implement this short-cut as it doesn't accept any bound parameters. It would be extremely useful if PrepareAndExecute supports bound parameters so that we don't have to make multiple trips to the server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1193) NullPointerException when trying to execute prepared statement using avatica
[
https://issues.apache.org/jira/browse/CALCITE-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15236119#comment-15236119
]
Francis Chuang commented on CALCITE-1193:
-
[~elserj] Thanks for looking into that! How do I spin up an avatica server by
itself? I am currently using Phoenix 4.8.0-SNAPSHOT which uses avatica 1.7.1
for the query server. I don't know how the phoenix query server is implementing
the avatica server, but I am starting to suspect that the prepared statement
not executing with an empty list of parameters might be a problem on Phoenix's
side.
When I run my test using {code}mvn test{code} in {code}calcite/avatica{code} it
also passes as well.
> NullPointerException when trying to execute prepared statement using avatica
>
>
> Key: CALCITE-1193
> URL: https://issues.apache.org/jira/browse/CALCITE-1193
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.7.1
> Environment: Phoenix 4.7.0 and Phoenix 4.8.0-SNAPSHOT
>Reporter: Francis Chuang
>Assignee: Josh Elser
>
> To reproduce, set the phoenix query server to use JSON for serialization:
> 1. Create a table called {{my_table}} and seed it using SquirrelSQL:
> {code}
> CREATE TABLE my_table (k BIGINT PRIMARY KEY, v VARCHAR) TRANSACTIONAL=true
> UPSERT INTO my_table VALUES (1,'A')
> UPSERT INTO my_table VALUES (2,'B')
> UPSERT INTO my_table VALUES (3,'C')
> UPSERT INTO my_table VALUES (4,'D')
> {code}
> Send the following requests using curl:
> {code}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request":
> "openConnection","connectionId": "my-conn"}'
> {"response":"openConnection","rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request": "prepare","connectionId":
> "my-conn","sql": "SELECT * FROM my_table","maxRowCount": 1}'
> {"response":"prepare","statement":{"connectionId":"my-conn","id":36,"signature":{"columns":[{"ordinal":0,"autoIncrement":false,"caseSensitive":false,"searchable":true,"currency":false,"nullable":0,"signed":true,"displaySize":40,"label":"K","columnName":"K","schemaName":"","precision":0,"scale":0,"tableName":"MY_TABLE","catalogName":"","type":{"type":"scalar","id":-5,"name":"BIGINT","rep":"PRIMITIVE_LONG"},"readOnly":true,"writable":false,"definitelyWritable":false,"columnClassName":"java.lang.Long"},{"ordinal":1,"autoIncrement":false,"caseSensitive":false,"searchable":true,"currency":false,"nullable":1,"signed":false,"displaySize":40,"label":"V","columnName":"V","schemaName":"","precision":0,"scale":0,"tableName":"MY_TABLE","catalogName":"","type":{"type":"scalar","id":12,"name":"VARCHAR","rep":"STRING"},"readOnly":true,"writable":false,"definitelyWritable":false,"columnClassName":"java.lang.String"}],"sql":"SELECT
> * FROM
> my_table","parameters":[],"cursorFactory":{"style":"LIST","clazz":null,"fieldNames":null},"statementType":null}},"rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request": "execute","statementHandle":
> {"connectionId": "my-conn","id": 36},"maxRowCount": 1}'
> {"response":"error","exceptions":["java.lang.NullPointerException\n\tat
> org.apache.calcite.avatica.MetaImpl.checkParameterValueHasNull(MetaImpl.java:952)\n\tat
> org.apache.calcite.avatica.jdbc.JdbcMeta.execute(JdbcMeta.java:781)\n\tat
> org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:233)\n\tat
>
> org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:950)\n\tat
>
> org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:928)\n\tat
>
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:102)\n\tat
>
> org.apache.calcite.avatica.remote.JsonHandler.apply(JsonHandler.java:43)\n\tat
>
> org.apache.calcite.avatica.server.AvaticaJsonHandler.handle(AvaticaJsonHandler.java:73)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:497)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:245)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)\n\tat
>
> java.lang.Thread.run(Thread.java:745)\n"],"errorMessage":"NullPointerException:
> (null
[jira] [Comment Edited] (CALCITE-1193) NullPointerException when trying to execute prepared statement using avatica
[
https://issues.apache.org/jira/browse/CALCITE-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15234523#comment-15234523
]
Francis Chuang edited comment on CALCITE-1193 at 4/11/16 6:00 AM:
--
[~elserj]. Here's a simple test case I came up with (hopefully it's valid
Java!). Let me know if it's able to reproduce the problem:
{code}
@Test public void testPreparedStatementWithoutParameters() throws Exception {
ConnectionSpec.getDatabaseLock().lock();
try (Connection conn = getLocalConnection();
Statement stmt = conn.createStatement()) {
assertTrue(stmt.execute("DROP TABLE IF EXISTS test"));
final String sql = "CREATE TABLE test(id integer)";
assertTrue(stmt.execute(sql));
PreparedStatement pstmt = conn.prepareStatement("SELECT * FROM test");
assertTrue(pstmt.execute());
} finally {
ConnectionSpec.getDatabaseLock().unlock();
}
}
{code}
To run, I used: mvn -DfailIfNoTests=false
-Dtest=RemoteDriverTest#testPreparedStatementWithoutParameters
-Dcheckstyle.skip=true -e test
was (Author: francischuang):
[~elserj]. Here's a simple test case I came up with (hopefully it's valid
Java!). Let me know if it's able to reproduce the problem:
{code}
@Test public void testPreparedStatementWithoutParameters() throws Exception {
ConnectionSpec.getDatabaseLock().lock();
try (Connection conn = getLocalConnection();
Statement stmt = conn.createStatement()) {
assertTrue(stmt.execute("DROP TABLE IF EXISTS test"));
final String sql = "CREATE TABLE test(id integer)";
assertTrue(stmt.execute(sql));
PreparedStatement pstmt = conn.prepareStatement("SELECT * FROM test");
assertTrue(pstmt.execute());
} finally {
ConnectionSpec.getDatabaseLock().unlock();
}
}
{code}
I run, I used: mvn -DfailIfNoTests=false
-Dtest=RemoteDriverTest#testPreparedStatementWithoutParameters
-Dcheckstyle.skip=true -e test
> NullPointerException when trying to execute prepared statement using avatica
>
>
> Key: CALCITE-1193
> URL: https://issues.apache.org/jira/browse/CALCITE-1193
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.7.1
> Environment: Phoenix 4.7.0 and Phoenix 4.8.0-SNAPSHOT
>Reporter: Francis Chuang
>Assignee: Josh Elser
>
> To reproduce, set the phoenix query server to use JSON for serialization:
> 1. Create a table called {{my_table}} and seed it using SquirrelSQL:
> {code}
> CREATE TABLE my_table (k BIGINT PRIMARY KEY, v VARCHAR) TRANSACTIONAL=true
> UPSERT INTO my_table VALUES (1,'A')
> UPSERT INTO my_table VALUES (2,'B')
> UPSERT INTO my_table VALUES (3,'C')
> UPSERT INTO my_table VALUES (4,'D')
> {code}
> Send the following requests using curl:
> {code}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request":
> "openConnection","connectionId": "my-conn"}'
> {"response":"openConnection","rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request": "prepare","connectionId":
> "my-conn","sql": "SELECT * FROM my_table","maxRowCount": 1}'
> {"response":"prepare","statement":{"connectionId":"my-conn","id":36,"signature":{"columns":[{"ordinal":0,"autoIncrement":false,"caseSensitive":false,"searchable":true,"currency":false,"nullable":0,"signed":true,"displaySize":40,"label":"K","columnName":"K","schemaName":"","precision":0,"scale":0,"tableName":"MY_TABLE","catalogName":"","type":{"type":"scalar","id":-5,"name":"BIGINT","rep":"PRIMITIVE_LONG"},"readOnly":true,"writable":false,"definitelyWritable":false,"columnClassName":"java.lang.Long"},{"ordinal":1,"autoIncrement":false,"caseSensitive":false,"searchable":true,"currency":false,"nullable":1,"signed":false,"displaySize":40,"label":"V","columnName":"V","schemaName":"","precision":0,"scale":0,"tableName":"MY_TABLE","catalogName":"","type":{"type":"scalar","id":12,"name":"VARCHAR","rep":"STRING"},"readOnly":true,"writable":false,"definitelyWritable":false,"columnClassName":"java.lang.String"}],"sql":"SELECT
> * FROM
> my_table","parameters":[],"cursorFactory":{"style":"LIST","clazz":null,"fieldNames":null},"statementType":null}},"rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request": "execute","statementHandle":
> {"connectionId": "my-conn","id": 36},"maxRowCount": 1}'
> {"response":"error","exceptions":["java.lang.NullPointerException\n\tat
> org.apache.calcite.avatica.MetaImpl.checkParameterValueHasNull(MetaImpl.java:952)\n\tat
> org.apache.calcite.avatica.jdbc.JdbcMeta.execute(JdbcMeta.java:781)\n\tat
>
[jira] [Updated] (CALCITE-1181) FetchResponse always return no rows
[
https://issues.apache.org/jira/browse/CALCITE-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis Chuang updated CALCITE-1181:
Description:
Assuming I have a table called my_table which is created and seeded like so:
{code:sql}
CREATE TABLE my_table (k BIGINT PRIMARY KEY, v VARCHAR) TRANSACTIONAL=true
UPSERT INTO my_table VALUES (1,'A')
UPSERT INTO my_table VALUES (2,'B')
{code}
I have 2 rows in the table. If I query the table using SELECT * FROM my_table,
and request a maxRowCount of 1, using FetchRequest to request further rows
always returns 0 rows.
For ease of reproduction, I have included CURL commands (avatica will need to
have serialization set to JSON):
{code}
curl localhost:8765 -XPOST --data '{"request": "openConnection","connectionId":
"my-conn"}'
curl localhost:8765 -XPOST --data '{"request":
"createStatement","connectionId": "my-conn"}'
curl localhost:8765 -XPOST --data '{"request":
"prepareAndExecute","connectionId": "my-conn","statementId": 12345,"sql":
"SELECT * FROM my_table","maxRowCount": 1}' # update the statementId
curl localhost:8765 -XPOST --data '{"request": "fetch","connectionId":
"my-conn","statementId": 12345,"offset": 0,"fetchMaxRowCount": 1}' # update the
statementId
{code}
was:
Assuming I have a table called my_table which is created and seeded like so:
CREATE TABLE my_table (k BIGINT PRIMARY KEY, v VARCHAR) TRANSACTIONAL=true
UPSERT INTO my_table VALUES (1,'A')
UPSERT INTO my_table VALUES (2,'B')
I have 2 rows in the table. If I query the table using SELECT * FROM my_table,
and request a maxRowCount of 1, using FetchRequest to request further rows
always returns 0 rows.
For ease of reproduction, I have included CURL commands (avatica will need to
have serialization set to JSON):
curl localhost:8765 -XPOST --data '{"request": "openConnection","connectionId":
"my-conn"}'
curl localhost:8765 -XPOST --data '{"request":
"createStatement","connectionId": "my-conn"}'
curl localhost:8765 -XPOST --data '{"request":
"prepareAndExecute","connectionId": "my-conn","statementId": 12345,"sql":
"SELECT * FROM my_table","maxRowCount": 1}' # update the statementId
curl localhost:8765 -XPOST --data '{"request": "fetch","connectionId":
"my-conn","statementId": 12345,"offset": 0,"fetchMaxRowCount": 1}' # update the
statementId
> FetchResponse always return no rows
> ---
>
> Key: CALCITE-1181
> URL: https://issues.apache.org/jira/browse/CALCITE-1181
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.7.1
> Environment: HBase 1.1 and Phoenix 4.7.0
>Reporter: Francis Chuang
>Assignee: Julian Hyde
>
> Assuming I have a table called my_table which is created and seeded like so:
> {code:sql}
> CREATE TABLE my_table (k BIGINT PRIMARY KEY, v VARCHAR) TRANSACTIONAL=true
> UPSERT INTO my_table VALUES (1,'A')
> UPSERT INTO my_table VALUES (2,'B')
> {code}
> I have 2 rows in the table. If I query the table using SELECT * FROM
> my_table, and request a maxRowCount of 1, using FetchRequest to request
> further rows always returns 0 rows.
> For ease of reproduction, I have included CURL commands (avatica will need to
> have serialization set to JSON):
> {code}
> curl localhost:8765 -XPOST --data '{"request":
> "openConnection","connectionId": "my-conn"}'
> curl localhost:8765 -XPOST --data '{"request":
> "createStatement","connectionId": "my-conn"}'
> curl localhost:8765 -XPOST --data '{"request":
> "prepareAndExecute","connectionId": "my-conn","statementId": 12345,"sql":
> "SELECT * FROM my_table","maxRowCount": 1}' # update the statementId
> curl localhost:8765 -XPOST --data '{"request": "fetch","connectionId":
> "my-conn","statementId": 12345,"offset": 0,"fetchMaxRowCount": 1}' # update
> the statementId
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1181) FetchResponse always return no rows
Francis Chuang created CALCITE-1181:
---
Summary: FetchResponse always return no rows
Key: CALCITE-1181
URL: https://issues.apache.org/jira/browse/CALCITE-1181
Project: Calcite
Issue Type: Bug
Components: avatica
Affects Versions: avatica-1.7.1
Environment: HBase 1.1 and Phoenix 4.7.0
Reporter: Francis Chuang
Assignee: Julian Hyde
Assuming I have a table called my_table which is created and seeded like so:
CREATE TABLE my_table (k BIGINT PRIMARY KEY, v VARCHAR) TRANSACTIONAL=true
UPSERT INTO my_table VALUES (1,'A')
UPSERT INTO my_table VALUES (2,'B')
I have 2 rows in the table. If I query the table using SELECT * FROM my_table,
and request a maxRowCount of 1, using FetchRequest to request further rows
always returns 0 rows.
For ease of reproduction, I have included CURL commands (avatica will need to
have serialization set to JSON):
curl localhost:8765 -XPOST --data '{"request": "openConnection","connectionId":
"my-conn"}'
curl localhost:8765 -XPOST --data '{"request":
"createStatement","connectionId": "my-conn"}'
curl localhost:8765 -XPOST --data '{"request":
"prepareAndExecute","connectionId": "my-conn","statementId": 12345,"sql":
"SELECT * FROM my_table","maxRowCount": 1}' # update the statementId
curl localhost:8765 -XPOST --data '{"request": "fetch","connectionId":
"my-conn","statementId": 12345,"offset": 0,"fetchMaxRowCount": 1}' # update the
statementId
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1181) FetchResponse always return no rows
[
https://issues.apache.org/jira/browse/CALCITE-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223523#comment-15223523
]
Francis Chuang edited comment on CALCITE-1181 at 4/3/16 9:55 PM:
-
In {{prepareAndExecute}}, I get 1 row back (the select statement should return
2 rows) and {{done}} is false.
When I use {{fetch}} to fetch the remaining row, {{done}} is true, but the
array of rows is empty.
was (Author: francischuang):
In {{prepareAndExecute}}, I get 1 row back (the select statement should return
2 rows) and {{done}} is false.
When I use {{fetch}} to fetch the remaining row, {{done}} is false, but the
array of rows is empty.
> FetchResponse always return no rows
> ---
>
> Key: CALCITE-1181
> URL: https://issues.apache.org/jira/browse/CALCITE-1181
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.7.1
> Environment: HBase 1.1 and Phoenix 4.7.0
>Reporter: Francis Chuang
>Assignee: Julian Hyde
>
> Assuming I have a table called my_table which is created and seeded like so:
> {code:sql}
> CREATE TABLE my_table (k BIGINT PRIMARY KEY, v VARCHAR) TRANSACTIONAL=true
> UPSERT INTO my_table VALUES (1,'A')
> UPSERT INTO my_table VALUES (2,'B')
> {code}
> I have 2 rows in the table. If I query the table using SELECT * FROM
> my_table, and request a maxRowCount of 1, using FetchRequest to request
> further rows always returns 0 rows.
> For ease of reproduction, I have included CURL commands (avatica will need to
> have serialization set to JSON):
> {code}
> curl localhost:8765 -XPOST --data '{"request":
> "openConnection","connectionId": "my-conn"}'
> curl localhost:8765 -XPOST --data '{"request":
> "createStatement","connectionId": "my-conn"}'
> curl localhost:8765 -XPOST --data '{"request":
> "prepareAndExecute","connectionId": "my-conn","statementId": 12345,"sql":
> "SELECT * FROM my_table","maxRowCount": 1}' # update the statementId
> curl localhost:8765 -XPOST --data '{"request": "fetch","connectionId":
> "my-conn","statementId": 12345,"offset": 0,"fetchMaxRowCount": 1}' # update
> the statementId
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1181) FetchResponse always return no rows
[
https://issues.apache.org/jira/browse/CALCITE-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223523#comment-15223523
]
Francis Chuang commented on CALCITE-1181:
-
In `prepareAndExecute`, I get 1 row back (the select statement should return 2
rows) and `done` is false.
When I use `fetch` to fetch the remaining row, `done` is false, but the array
of rows is empty.
> FetchResponse always return no rows
> ---
>
> Key: CALCITE-1181
> URL: https://issues.apache.org/jira/browse/CALCITE-1181
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.7.1
> Environment: HBase 1.1 and Phoenix 4.7.0
>Reporter: Francis Chuang
>Assignee: Julian Hyde
>
> Assuming I have a table called my_table which is created and seeded like so:
> {code:sql}
> CREATE TABLE my_table (k BIGINT PRIMARY KEY, v VARCHAR) TRANSACTIONAL=true
> UPSERT INTO my_table VALUES (1,'A')
> UPSERT INTO my_table VALUES (2,'B')
> {code}
> I have 2 rows in the table. If I query the table using SELECT * FROM
> my_table, and request a maxRowCount of 1, using FetchRequest to request
> further rows always returns 0 rows.
> For ease of reproduction, I have included CURL commands (avatica will need to
> have serialization set to JSON):
> {code}
> curl localhost:8765 -XPOST --data '{"request":
> "openConnection","connectionId": "my-conn"}'
> curl localhost:8765 -XPOST --data '{"request":
> "createStatement","connectionId": "my-conn"}'
> curl localhost:8765 -XPOST --data '{"request":
> "prepareAndExecute","connectionId": "my-conn","statementId": 12345,"sql":
> "SELECT * FROM my_table","maxRowCount": 1}' # update the statementId
> curl localhost:8765 -XPOST --data '{"request": "fetch","connectionId":
> "my-conn","statementId": 12345,"offset": 0,"fetchMaxRowCount": 1}' # update
> the statementId
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1181) FetchResponse always return no rows
[
https://issues.apache.org/jira/browse/CALCITE-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223523#comment-15223523
]
Francis Chuang edited comment on CALCITE-1181 at 4/3/16 9:52 PM:
-
In {code}prepareAndExecute{code}, I get 1 row back (the select statement should
return 2 rows) and {code}done{code} is false.
When I use {code}fetch{code} to fetch the remaining row, {code}done{code} is
false, but the array of rows is empty.
was (Author: francischuang):
In `prepareAndExecute`, I get 1 row back (the select statement should return 2
rows) and `done` is false.
When I use `fetch` to fetch the remaining row, `done` is false, but the array
of rows is empty.
> FetchResponse always return no rows
> ---
>
> Key: CALCITE-1181
> URL: https://issues.apache.org/jira/browse/CALCITE-1181
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.7.1
> Environment: HBase 1.1 and Phoenix 4.7.0
>Reporter: Francis Chuang
>Assignee: Julian Hyde
>
> Assuming I have a table called my_table which is created and seeded like so:
> {code:sql}
> CREATE TABLE my_table (k BIGINT PRIMARY KEY, v VARCHAR) TRANSACTIONAL=true
> UPSERT INTO my_table VALUES (1,'A')
> UPSERT INTO my_table VALUES (2,'B')
> {code}
> I have 2 rows in the table. If I query the table using SELECT * FROM
> my_table, and request a maxRowCount of 1, using FetchRequest to request
> further rows always returns 0 rows.
> For ease of reproduction, I have included CURL commands (avatica will need to
> have serialization set to JSON):
> {code}
> curl localhost:8765 -XPOST --data '{"request":
> "openConnection","connectionId": "my-conn"}'
> curl localhost:8765 -XPOST --data '{"request":
> "createStatement","connectionId": "my-conn"}'
> curl localhost:8765 -XPOST --data '{"request":
> "prepareAndExecute","connectionId": "my-conn","statementId": 12345,"sql":
> "SELECT * FROM my_table","maxRowCount": 1}' # update the statementId
> curl localhost:8765 -XPOST --data '{"request": "fetch","connectionId":
> "my-conn","statementId": 12345,"offset": 0,"fetchMaxRowCount": 1}' # update
> the statementId
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1181) FetchResponse always return no rows
[
https://issues.apache.org/jira/browse/CALCITE-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223523#comment-15223523
]
Francis Chuang edited comment on CALCITE-1181 at 4/3/16 9:53 PM:
-
In {{prepareAndExecute}}, I get 1 row back (the select statement should return
2 rows) and {{done}} is false.
When I use {[fetch}} to fetch the remaining row, {{done}} is false, but the
array of rows is empty.
was (Author: francischuang):
In {code}prepareAndExecute{code}, I get 1 row back (the select statement should
return 2 rows) and {code}done{code} is false.
When I use {code}fetch{code} to fetch the remaining row, {code}done{code} is
false, but the array of rows is empty.
> FetchResponse always return no rows
> ---
>
> Key: CALCITE-1181
> URL: https://issues.apache.org/jira/browse/CALCITE-1181
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.7.1
> Environment: HBase 1.1 and Phoenix 4.7.0
>Reporter: Francis Chuang
>Assignee: Julian Hyde
>
> Assuming I have a table called my_table which is created and seeded like so:
> {code:sql}
> CREATE TABLE my_table (k BIGINT PRIMARY KEY, v VARCHAR) TRANSACTIONAL=true
> UPSERT INTO my_table VALUES (1,'A')
> UPSERT INTO my_table VALUES (2,'B')
> {code}
> I have 2 rows in the table. If I query the table using SELECT * FROM
> my_table, and request a maxRowCount of 1, using FetchRequest to request
> further rows always returns 0 rows.
> For ease of reproduction, I have included CURL commands (avatica will need to
> have serialization set to JSON):
> {code}
> curl localhost:8765 -XPOST --data '{"request":
> "openConnection","connectionId": "my-conn"}'
> curl localhost:8765 -XPOST --data '{"request":
> "createStatement","connectionId": "my-conn"}'
> curl localhost:8765 -XPOST --data '{"request":
> "prepareAndExecute","connectionId": "my-conn","statementId": 12345,"sql":
> "SELECT * FROM my_table","maxRowCount": 1}' # update the statementId
> curl localhost:8765 -XPOST --data '{"request": "fetch","connectionId":
> "my-conn","statementId": 12345,"offset": 0,"fetchMaxRowCount": 1}' # update
> the statementId
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1181) FetchResponse always return no rows
[
https://issues.apache.org/jira/browse/CALCITE-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis Chuang updated CALCITE-1181:
Environment: HBase 1.1 and Phoenix 4.7.0, HBase 1.1 and Phoenix
4.8.0-SNAPSHOT (was: HBase 1.1 and Phoenix 4.7.0)
> FetchResponse always return no rows
> ---
>
> Key: CALCITE-1181
> URL: https://issues.apache.org/jira/browse/CALCITE-1181
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.7.1
> Environment: HBase 1.1 and Phoenix 4.7.0, HBase 1.1 and Phoenix
> 4.8.0-SNAPSHOT
>Reporter: Francis Chuang
>Assignee: Julian Hyde
>
> Assuming I have a table called my_table which is created and seeded like so:
> {code:sql}
> CREATE TABLE my_table (k BIGINT PRIMARY KEY, v VARCHAR) TRANSACTIONAL=true
> UPSERT INTO my_table VALUES (1,'A')
> UPSERT INTO my_table VALUES (2,'B')
> {code}
> I have 2 rows in the table. If I query the table using SELECT * FROM
> my_table, and request a maxRowCount of 1, using FetchRequest to request
> further rows always returns 0 rows.
> For ease of reproduction, I have included CURL commands (avatica will need to
> have serialization set to JSON):
> {code}
> curl localhost:8765 -XPOST --data '{"request":
> "openConnection","connectionId": "my-conn"}'
> curl localhost:8765 -XPOST --data '{"request":
> "createStatement","connectionId": "my-conn"}'
> curl localhost:8765 -XPOST --data '{"request":
> "prepareAndExecute","connectionId": "my-conn","statementId": 12345,"sql":
> "SELECT * FROM my_table","maxRowCount": 1}' # update the statementId
> curl localhost:8765 -XPOST --data '{"request": "fetch","connectionId":
> "my-conn","statementId": 12345,"offset": 0,"fetchMaxRowCount": 1}' # update
> the statementId
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1181) FetchResponse always return no rows
[
https://issues.apache.org/jira/browse/CALCITE-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223609#comment-15223609
]
Francis Chuang commented on CALCITE-1181:
-
I just tested Phoenix 4.8.0-SNAPSHOT which uses avatica 1.7.1 and it also
exhibits the same problem.
> FetchResponse always return no rows
> ---
>
> Key: CALCITE-1181
> URL: https://issues.apache.org/jira/browse/CALCITE-1181
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.7.1
> Environment: HBase 1.1 and Phoenix 4.7.0
>Reporter: Francis Chuang
>Assignee: Julian Hyde
>
> Assuming I have a table called my_table which is created and seeded like so:
> {code:sql}
> CREATE TABLE my_table (k BIGINT PRIMARY KEY, v VARCHAR) TRANSACTIONAL=true
> UPSERT INTO my_table VALUES (1,'A')
> UPSERT INTO my_table VALUES (2,'B')
> {code}
> I have 2 rows in the table. If I query the table using SELECT * FROM
> my_table, and request a maxRowCount of 1, using FetchRequest to request
> further rows always returns 0 rows.
> For ease of reproduction, I have included CURL commands (avatica will need to
> have serialization set to JSON):
> {code}
> curl localhost:8765 -XPOST --data '{"request":
> "openConnection","connectionId": "my-conn"}'
> curl localhost:8765 -XPOST --data '{"request":
> "createStatement","connectionId": "my-conn"}'
> curl localhost:8765 -XPOST --data '{"request":
> "prepareAndExecute","connectionId": "my-conn","statementId": 12345,"sql":
> "SELECT * FROM my_table","maxRowCount": 1}' # update the statementId
> curl localhost:8765 -XPOST --data '{"request": "fetch","connectionId":
> "my-conn","statementId": 12345,"offset": 0,"fetchMaxRowCount": 1}' # update
> the statementId
> {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=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] [Commented] (CALCITE-1181) FetchResponse always return no rows
[
https://issues.apache.org/jira/browse/CALCITE-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15273679#comment-15273679
]
Francis Chuang commented on CALCITE-1181:
-
I attempted to implement {{prepareAndExecute}} in my golang driver and hit this
issue again. I was able to narrow the problem down with my tests.
This issue does not exist if you use the "long way": {{PrepareRequest}},
{{ExecuteRequest}}, {{FetchRequest}}.
The problem only exists if you attempt to use {{prepareAndExecute}} and then
use {{FetchRequest}} to fetch more rows.
The current work around is to use the "long way" when querying.
> FetchResponse always return no rows
> ---
>
> Key: CALCITE-1181
> URL: https://issues.apache.org/jira/browse/CALCITE-1181
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.7.1
> Environment: HBase 1.1 and Phoenix 4.7.0, HBase 1.1 and Phoenix
> 4.8.0-SNAPSHOT
>Reporter: Francis Chuang
>Assignee: Julian Hyde
>
> Assuming I have a table called my_table which is created and seeded like so:
> {code:sql}
> CREATE TABLE my_table (k BIGINT PRIMARY KEY, v VARCHAR) TRANSACTIONAL=true
> UPSERT INTO my_table VALUES (1,'A')
> UPSERT INTO my_table VALUES (2,'B')
> {code}
> I have 2 rows in the table. If I query the table using SELECT * FROM
> my_table, and request a maxRowCount of 1, using FetchRequest to request
> further rows always returns 0 rows.
> For ease of reproduction, I have included CURL commands (avatica will need to
> have serialization set to JSON):
> {code}
> curl localhost:8765 -XPOST --data '{"request":
> "openConnection","connectionId": "my-conn"}'
> curl localhost:8765 -XPOST --data '{"request":
> "createStatement","connectionId": "my-conn"}'
> curl localhost:8765 -XPOST --data '{"request":
> "prepareAndExecute","connectionId": "my-conn","statementId": 12345,"sql":
> "SELECT * FROM my_table","maxRowCount": 1}' # update the statementId
> curl localhost:8765 -XPOST --data '{"request": "fetch","connectionId":
> "my-conn","statementId": 12345,"offset": 0,"fetchMaxRowCount": 1}' # update
> the statementId
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1192) Document protobuf and json REP types with examples
[ https://issues.apache.org/jira/browse/CALCITE-1192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15246665#comment-15246665 ] Francis Chuang commented on CALCITE-1192: - Looks great! :) > Document protobuf and json REP types with examples > -- > > Key: CALCITE-1192 > URL: https://issues.apache.org/jira/browse/CALCITE-1192 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Francis Chuang >Assignee: Josh Elser > Fix For: avatica-1.8.0 > > > It would be nice to have the documentation for the Rep types here > (https://calcite.apache.org/docs/avatica_protobuf_reference.html#rep) > documented with examples to show what the serialized representation looks > like. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1192) Document protobuf and json REP types with examples
[ https://issues.apache.org/jira/browse/CALCITE-1192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15244943#comment-15244943 ] Francis Chuang commented on CALCITE-1192: - That looks great! For the bytes_value field, I believe it should be bytes_values as per https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/common.proto#L199 Also, I think it would be useful to have some notes regarding the time values, for example: - Date is the number of days since 1/1/1970. - Time is the number of milliseconds since 00:00:00:000 - Timestamp is the number of milliseconds since 1/1/1970 00:00:00:000 > Document protobuf and json REP types with examples > -- > > Key: CALCITE-1192 > URL: https://issues.apache.org/jira/browse/CALCITE-1192 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Francis Chuang >Assignee: Josh Elser > Fix For: avatica-1.8.0 > > > It would be nice to have the documentation for the Rep types here > (https://calcite.apache.org/docs/avatica_protobuf_reference.html#rep) > documented with examples to show what the serialized representation looks > like. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1209) Byte strings not being correctly decoded when sent to avatica using protocol buffers
Francis Chuang created CALCITE-1209:
---
Summary: Byte strings not being correctly decoded when sent to
avatica using protocol buffers
Key: CALCITE-1209
URL: https://issues.apache.org/jira/browse/CALCITE-1209
Project: Calcite
Issue Type: Bug
Components: avatica
Affects Versions: avatica-1.7.1
Reporter: Francis Chuang
When sending a typed value as a byte string to avatica using protocol buffers,
it does not accept the bytes as an array of raw bytes in the {{bytes_values}}
field.
To work around it, the data needs to be first base64 encoded and then sent in
the {{string_value}} field.
This is the decoded protocol buffer being sent by the thin client:
{code}
1: "org.apache.calcite.avatica.proto.Requests$ExecuteRequest"
2 {
1 {
1: "5141356e-f331-48c9-9d01-d71176ad92e8"
2: 126
3 {
2: "UPSERT INTO PQS.INTEGER_TABLE VALUES(?, ?)"
3 {
4: 4
5: "INTEGER"
6: "java.lang.Integer"
7: "?1"
}
3 {
4: 4294967293
5: "VARBINARY"
6: "[B"
7: "?2"
}
4 {
1: 4
}
}
}
2 {
1: 12
4: 2
}
2 {
1: 20
// Data sent in string_value and base64 encoded
3: "iVBORw0KGgoNSUhEUgAABmIAAAiwCAYvCT8OCXBI..."
}
3: 100
4: 1
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CALCITE-1181) FetchResponse always return no rows
[
https://issues.apache.org/jira/browse/CALCITE-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis Chuang closed CALCITE-1181.
---
Resolution: Fixed
Fix Version/s: 1.8.0
> FetchResponse always return no rows
> ---
>
> Key: CALCITE-1181
> URL: https://issues.apache.org/jira/browse/CALCITE-1181
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.7.1
> Environment: HBase 1.1 and Phoenix 4.7.0, HBase 1.1 and Phoenix
> 4.8.0-SNAPSHOT
>Reporter: Francis Chuang
>Assignee: Julian Hyde
> Fix For: 1.8.0
>
>
> Assuming I have a table called my_table which is created and seeded like so:
> {code:sql}
> CREATE TABLE my_table (k BIGINT PRIMARY KEY, v VARCHAR) TRANSACTIONAL=true
> UPSERT INTO my_table VALUES (1,'A')
> UPSERT INTO my_table VALUES (2,'B')
> {code}
> I have 2 rows in the table. If I query the table using SELECT * FROM
> my_table, and request a maxRowCount of 1, using FetchRequest to request
> further rows always returns 0 rows.
> For ease of reproduction, I have included CURL commands (avatica will need to
> have serialization set to JSON):
> {code}
> curl localhost:8765 -XPOST --data '{"request":
> "openConnection","connectionId": "my-conn"}'
> curl localhost:8765 -XPOST --data '{"request":
> "createStatement","connectionId": "my-conn"}'
> curl localhost:8765 -XPOST --data '{"request":
> "prepareAndExecute","connectionId": "my-conn","statementId": 12345,"sql":
> "SELECT * FROM my_table","maxRowCount": 1}' # update the statementId
> curl localhost:8765 -XPOST --data '{"request": "fetch","connectionId":
> "my-conn","statementId": 12345,"offset": 0,"fetchMaxRowCount": 1}' # update
> the statementId
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1353) first_frame_max_size in an ExecuteRequest should be an int32 in protobuf definitions.
Francis Chuang created CALCITE-1353:
---
Summary: first_frame_max_size in an ExecuteRequest should be an
int32 in protobuf definitions.
Key: CALCITE-1353
URL: https://issues.apache.org/jira/browse/CALCITE-1353
Project: Calcite
Issue Type: Bug
Components: avatica
Reporter: Francis Chuang
Priority: Minor
In the protobuf definition for {{ExecuteRequest}}, the {{first_frame_max_size}}
parameter is typed as an {{uint64}}. See
https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L130.
For consistency, it should be an {{int32}}.
Similar parameters relating to the frame size are all typed as {{int32}}.
For a {{PrepareAndExecuteRequest}}, {{first_frame_max_size}} is a{{int32}}:
https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L78
For a {{FetchRequest}}, {{frame_max_size}} is a {{int32}}:
https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L96
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1352) Clarify documentation for avatica's max_rows_total
[
https://issues.apache.org/jira/browse/CALCITE-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis Chuang updated CALCITE-1352:
Summary: Clarify documentation for avatica's max_rows_total (was: Clarify
documentation for avatica's max_row_totals)
> Clarify documentation for avatica's max_rows_total
> --
>
> Key: CALCITE-1352
> URL: https://issues.apache.org/jira/browse/CALCITE-1352
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Francis Chuang
>Priority: Minor
>
> The {{max_rows_total}} parameter in the protocol buffer definitions should be
> updated to include more information on values that result in unlimited rows
> being returned.
> When testing against calcite 1.8.0, I observed the following:
> {code}
> -1: Unlimited number of rows
> 0: 0 rows
> 1: 1 row
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1353) first_frame_max_size in an ExecuteRequest should be an int32 in protobuf definitions.
[
https://issues.apache.org/jira/browse/CALCITE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15886538#comment-15886538
]
Francis Chuang commented on CALCITE-1353:
-
I am going to close that PR as it breaks backwards compatibility. I believe the
best way would be to introduce a new field under a new name, so that older
clients won't be broken.
> first_frame_max_size in an ExecuteRequest should be an int32 in protobuf
> definitions.
> -
>
> Key: CALCITE-1353
> URL: https://issues.apache.org/jira/browse/CALCITE-1353
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Francis Chuang
>Assignee: Francis Chuang
>Priority: Minor
> Fix For: avatica-1.10.0
>
>
> In the protobuf definition for {{ExecuteRequest}}, the
> {{first_frame_max_size}} parameter is typed as an {{uint64}}. See
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L130.
> For consistency, it should be an {{int32}}.
> Similar parameters relating to the frame size are all typed as {{int32}}.
> For a {{PrepareAndExecuteRequest}}, {{first_frame_max_size}} is a{{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L78
> For a {{FetchRequest}}, {{frame_max_size}} is a {{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L96
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1354) Release Avatica 1.9.0
[ https://issues.apache.org/jira/browse/CALCITE-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15460562#comment-15460562 ] Francis Chuang commented on CALCITE-1354: - Can CALCITE-1353 make it into this release? > Release Avatica 1.9.0 > - > > Key: CALCITE-1354 > URL: https://issues.apache.org/jira/browse/CALCITE-1354 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Josh Elser > Fix For: avatica-1.9.0 > > > General issue to track the release (so I can better track downstream projects > waiting on fixes from Avatica to be released). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1369) Display a list of Avatica clients on the website
[ https://issues.apache.org/jira/browse/CALCITE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang updated CALCITE-1369: Description: I think it would be really neat to have a well organized list of Avatica clients on the website. This would make clients much more discoverable and make Avatica and Calcite much more easier for people to get started with. For example, Kafka has a wiki page with their clients here: https://cwiki.apache.org/confluence/display/KAFKA/Clients 1. Most of the clients currently available (the .NET and python ones) are currently targeted towards Apache Phoenix. Should we include these clients? If not, is there a process for reaching out to their maintainers to see if they are interested in generalising them to target Avatica? 2. Is there any process for including a client on such a page? Should anyone be able to add the client, or do we need explicit permission from the maintainers? 3. To reduce friction, is it viable to have a wiki page, so that maintainers can easily add their own clients? was: I think it would be really neat to have a well organized list of Avatica clients on the website. This would make clients much more discoverable and make Avatica and Calcite much more easier for people to get started with. For example, Kafka have a wiki page with their clients here: https://cwiki.apache.org/confluence/display/KAFKA/Clients 1. Most of the clients currently available (the .NET and python ones) are currently targeted towards Apache Phoenix. Should we include these clients? If not, is there a process for reaching out to their maintainers to see if they are interested in generalising them to target Avatica? 2. Is there any process for including a client on such a page? Should anyone be able to add the client, or do we need explicit permission from the maintainers? 3. To reduce friction, is it viable to have a wiki page, so that maintainers can easily add their own clients? > Display a list of Avatica clients on the website > > > Key: CALCITE-1369 > URL: https://issues.apache.org/jira/browse/CALCITE-1369 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Francis Chuang >Priority: Minor > > I think it would be really neat to have a well organized list of Avatica > clients on the website. This would make clients much more discoverable and > make Avatica and Calcite much more easier for people to get started with. For > example, Kafka has a wiki page with their clients here: > https://cwiki.apache.org/confluence/display/KAFKA/Clients > 1. Most of the clients currently available (the .NET and python ones) are > currently targeted towards Apache Phoenix. Should we include these clients? > If not, is there a process for reaching out to their maintainers to see if > they are interested in generalising them to target Avatica? > 2. Is there any process for including a client on such a page? Should anyone > be able to add the client, or do we need explicit permission from the > maintainers? > 3. To reduce friction, is it viable to have a wiki page, so that maintainers > can easily add their own clients? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1369) Display a list of Avatica clients on the website
Francis Chuang created CALCITE-1369: --- Summary: Display a list of Avatica clients on the website Key: CALCITE-1369 URL: https://issues.apache.org/jira/browse/CALCITE-1369 Project: Calcite Issue Type: Improvement Components: avatica Reporter: Francis Chuang Priority: Minor I think it would be really neat to have a well organized list of Avatica clients on the website. This would make clients much more discoverable and make Avatica and Calcite much more easier for people to get started with. For example, Kafka have a wiki page with their clients here: https://cwiki.apache.org/confluence/display/KAFKA/Clients 1. Most of the clients currently available (the .NET and python ones) are currently targeted towards Apache Phoenix. Should we include these clients? If not, is there a process for reaching out to their maintainers to see if they are interested in generalising them to target Avatica? 2. Is there any process for including a client on such a page? Should anyone be able to add the client, or do we need explicit permission from the maintainers? 3. To reduce friction, is it viable to have a wiki page, so that maintainers can easily add their own clients? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1412) Use Wercker instead of Travis-CI
[ https://issues.apache.org/jira/browse/CALCITE-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15547140#comment-15547140 ] Francis Chuang edited comment on CALCITE-1412 at 10/5/16 12:14 AM: --- [~julianhyde] Wercker has a build status image, just like the one used in travis. For example, here's the one for my fork's use-wercker branch: https://app.wercker.com/status/23565d2b5a556e4c73c18696654a432f/s/use-wercker After enabling the testExplainJoin3 test, the build failed on both JDK-7 and JDK-8, this does not seem to be a timeout, but rather the test not passing. See here for the logs: https://app.wercker.com/F21/calcite/runs/build-jdk-7/57f4431f072c590100317557?step=57f44325ec04d50001ba11cf I think I will revert the commit to enable testExplainJoin3 for this change for now. The test can be renabled when it's fixed. was (Author: francischuang): [~julianhyde] Wercker has a build status image, just like the one used in travis. For example, here's the one for my fork's use-wercker branch: https://app.wercker.com/status/23565d2b5a556e4c73c18696654a432f/s/use-wercker After enabling the textExaplinJoin3 test, the build failed on both JDK-7 and JDK-8, this does not seem to be a timeout, but rather the test not passing. See here for the logs: https://app.wercker.com/F21/calcite/runs/build-jdk-7/57f4431f072c590100317557?step=57f44325ec04d50001ba11cf > Use Wercker instead of Travis-CI > > > Key: CALCITE-1412 > URL: https://issues.apache.org/jira/browse/CALCITE-1412 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Francis Chuang > > There are reports that Wercker is less prone to hanging when running tests > than Travis CI. We should investigate. > [~francischuang], can you attach a pull request? > Does Wercker have an equivalent of the "build status" at the top of README.md? > Also can you see whether you can re-enable JdbcTest.testExplainJoin3 (which > is disabled due to OutOfMemoryError on Travis). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1412) Use Wercker instead of Travis-CI
[ https://issues.apache.org/jira/browse/CALCITE-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15547140#comment-15547140 ] Francis Chuang commented on CALCITE-1412: - [~julianhyde] Wercker has a build status image, just like the one used in travis. For example, here's the one for my fork's use-wercker branch: https://app.wercker.com/status/23565d2b5a556e4c73c18696654a432f/s/use-wercker After enabling the textExaplinJoin3 test, the build failed on both JDK-7 and JDK-8, this does not seem to be a timeout, but rather the test not passing. See here for the logs: https://app.wercker.com/F21/calcite/runs/build-jdk-7/57f4431f072c590100317557?step=57f44325ec04d50001ba11cf > Use Wercker instead of Travis-CI > > > Key: CALCITE-1412 > URL: https://issues.apache.org/jira/browse/CALCITE-1412 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Francis Chuang > > There are reports that Wercker is less prone to hanging when running tests > than Travis CI. We should investigate. > [~francischuang], can you attach a pull request? > Does Wercker have an equivalent of the "build status" at the top of README.md? > Also can you see whether you can re-enable JdbcTest.testExplainJoin3 (which > is disabled due to OutOfMemoryError on Travis). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1412) Use Wercker instead of Travis-CI
[ https://issues.apache.org/jira/browse/CALCITE-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15547155#comment-15547155 ] Francis Chuang commented on CALCITE-1412: - [~elserj] also mentioned the possibility of using jenkins build machines provided by the ASF. > Use Wercker instead of Travis-CI > > > Key: CALCITE-1412 > URL: https://issues.apache.org/jira/browse/CALCITE-1412 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Francis Chuang > > There are reports that Wercker is less prone to hanging when running tests > than Travis CI. We should investigate. > [~francischuang], can you attach a pull request? > Does Wercker have an equivalent of the "build status" at the top of README.md? > Also can you see whether you can re-enable JdbcTest.testExplainJoin3 (which > is disabled due to OutOfMemoryError on Travis). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1353) first_frame_max_size in an ExecuteRequest should be an int32 in protobuf definitions.
[
https://issues.apache.org/jira/browse/CALCITE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15603499#comment-15603499
]
Francis Chuang commented on CALCITE-1353:
-
Good point, [~elserj]. Go does have uint64 and int32 types. With the Go driver,
this change would require a minor update to the client. The code currently
casts the int32 to a uint64, so if it is set to -1, it overflows to
18446744073709551615, which should be pretty much "all" rows. Changing it to
an int32 would require me to remove the cast from int32 to uint64, but I
believe it is much better than relying on the overflowing behaviour.
For backwards compatibility, I think the idea of introducing a new field is
probably the best way forward. In this case, do you have a proposed name for
the field?
I also think it would be nice to incorporate changes to maxRowCount into this
(totally missed that!), but again, if we want a new field, we need to decide on
a suitable name.
> first_frame_max_size in an ExecuteRequest should be an int32 in protobuf
> definitions.
> -
>
> Key: CALCITE-1353
> URL: https://issues.apache.org/jira/browse/CALCITE-1353
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Francis Chuang
>Priority: Minor
> Fix For: avatica-1.10.0
>
>
> In the protobuf definition for {{ExecuteRequest}}, the
> {{first_frame_max_size}} parameter is typed as an {{uint64}}. See
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L130.
> For consistency, it should be an {{int32}}.
> Similar parameters relating to the frame size are all typed as {{int32}}.
> For a {{PrepareAndExecuteRequest}}, {{first_frame_max_size}} is a{{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L78
> For a {{FetchRequest}}, {{frame_max_size}} is a {{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L96
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1353) first_frame_max_size in an ExecuteRequest should be an int32 in protobuf definitions.
[
https://issues.apache.org/jira/browse/CALCITE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15603557#comment-15603557
]
Francis Chuang commented on CALCITE-1353:
-
Perhaps it might also be a good time to do an audit on all the fields so we can
deprecate/introduce the new fields in 1.10.
> first_frame_max_size in an ExecuteRequest should be an int32 in protobuf
> definitions.
> -
>
> Key: CALCITE-1353
> URL: https://issues.apache.org/jira/browse/CALCITE-1353
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Francis Chuang
>Priority: Minor
> Fix For: avatica-1.10.0
>
>
> In the protobuf definition for {{ExecuteRequest}}, the
> {{first_frame_max_size}} parameter is typed as an {{uint64}}. See
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L130.
> For consistency, it should be an {{int32}}.
> Similar parameters relating to the frame size are all typed as {{int32}}.
> For a {{PrepareAndExecuteRequest}}, {{first_frame_max_size}} is a{{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L78
> For a {{FetchRequest}}, {{frame_max_size}} is a {{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L96
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1353) first_frame_max_size in an ExecuteRequest should be an int32 in protobuf definitions.
[
https://issues.apache.org/jira/browse/CALCITE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15603383#comment-15603383
]
Francis Chuang commented on CALCITE-1353:
-
See https://github.com/apache/calcite/pull/319
> first_frame_max_size in an ExecuteRequest should be an int32 in protobuf
> definitions.
> -
>
> Key: CALCITE-1353
> URL: https://issues.apache.org/jira/browse/CALCITE-1353
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Francis Chuang
>Priority: Minor
> Fix For: avatica-1.10.0
>
>
> In the protobuf definition for {{ExecuteRequest}}, the
> {{first_frame_max_size}} parameter is typed as an {{uint64}}. See
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L130.
> For consistency, it should be an {{int32}}.
> Similar parameters relating to the frame size are all typed as {{int32}}.
> For a {{PrepareAndExecuteRequest}}, {{first_frame_max_size}} is a{{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L78
> For a {{FetchRequest}}, {{frame_max_size}} is a {{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L96
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1353) first_frame_max_size in an ExecuteRequest should be an int32 in protobuf definitions.
[
https://issues.apache.org/jira/browse/CALCITE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15623380#comment-15623380
]
Francis Chuang commented on CALCITE-1353:
-
[~julianhyde] Not a problem! I would absolutely love to get this one resolved.
[~elserj] Any thoughts on how we should approach this for backwards
compatibility?
> first_frame_max_size in an ExecuteRequest should be an int32 in protobuf
> definitions.
> -
>
> Key: CALCITE-1353
> URL: https://issues.apache.org/jira/browse/CALCITE-1353
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Francis Chuang
>Assignee: Francis Chuang
>Priority: Minor
> Fix For: avatica-1.10.0
>
>
> In the protobuf definition for {{ExecuteRequest}}, the
> {{first_frame_max_size}} parameter is typed as an {{uint64}}. See
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L130.
> For consistency, it should be an {{int32}}.
> Similar parameters relating to the frame size are all typed as {{int32}}.
> For a {{PrepareAndExecuteRequest}}, {{first_frame_max_size}} is a{{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L78
> For a {{FetchRequest}}, {{frame_max_size}} is a {{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L96
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1084) Set up Yetus-based PreCommit build
[ https://issues.apache.org/jira/browse/CALCITE-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15566943#comment-15566943 ] Francis Chuang commented on CALCITE-1084: - I looked at the yetus project over the weekend, but it is still unclear what it does for Calcite. Can someone please bring me up to speed? > Set up Yetus-based PreCommit build > -- > > Key: CALCITE-1084 > URL: https://issues.apache.org/jira/browse/CALCITE-1084 > Project: Calcite > Issue Type: Task >Reporter: Josh Elser >Assignee: Julian Hyde > > We got Jenkins-based CI in CALCITE-623. Let's get some ASF-hosted pre-commit > builds that can be used before we commit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1412) Use Wercker instead of Travis-CI
[ https://issues.apache.org/jira/browse/CALCITE-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15566947#comment-15566947 ] Francis Chuang commented on CALCITE-1412: - Integration with Wercker seems to be impossible according to INFRA as they are not able to allow write access to repos from third parities. > Use Wercker instead of Travis-CI > > > Key: CALCITE-1412 > URL: https://issues.apache.org/jira/browse/CALCITE-1412 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Francis Chuang > > There are reports that Wercker is less prone to hanging when running tests > than Travis CI. We should investigate. > [~francischuang], can you attach a pull request? > Does Wercker have an equivalent of the "build status" at the top of README.md? > Also can you see whether you can re-enable JdbcTest.testExplainJoin3 (which > is disabled due to OutOfMemoryError on Travis). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1084) Set up Yetus-based PreCommit build
[ https://issues.apache.org/jira/browse/CALCITE-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15567698#comment-15567698 ] Francis Chuang commented on CALCITE-1084: - [~elserj], thanks, that makes sense now! In that case, how important would that be? Since our travis tests are failing, I think it would probably be nice if we can get the ASFBot to build our Github PRs as a starter and circle back to this one. > Set up Yetus-based PreCommit build > -- > > Key: CALCITE-1084 > URL: https://issues.apache.org/jira/browse/CALCITE-1084 > Project: Calcite > Issue Type: Task >Reporter: Josh Elser >Assignee: Julian Hyde > > We got Jenkins-based CI in CALCITE-623. Let's get some ASF-hosted pre-commit > builds that can be used before we commit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1412) Use Wercker instead of Travis-CI
[ https://issues.apache.org/jira/browse/CALCITE-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang resolved CALCITE-1412. - Resolution: Won't Fix Since it's ASF policy to not allow third parties write access to a repo, setting up Wercker to run our tests won't be possible. > Use Wercker instead of Travis-CI > > > Key: CALCITE-1412 > URL: https://issues.apache.org/jira/browse/CALCITE-1412 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Francis Chuang > > There are reports that Wercker is less prone to hanging when running tests > than Travis CI. We should investigate. > [~francischuang], can you attach a pull request? > Does Wercker have an equivalent of the "build status" at the top of README.md? > Also can you see whether you can re-enable JdbcTest.testExplainJoin3 (which > is disabled due to OutOfMemoryError on Travis). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CALCITE-1412) Use Wercker instead of Travis-CI
[ https://issues.apache.org/jira/browse/CALCITE-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang closed CALCITE-1412. --- > Use Wercker instead of Travis-CI > > > Key: CALCITE-1412 > URL: https://issues.apache.org/jira/browse/CALCITE-1412 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Francis Chuang > > There are reports that Wercker is less prone to hanging when running tests > than Travis CI. We should investigate. > [~francischuang], can you attach a pull request? > Does Wercker have an equivalent of the "build status" at the top of README.md? > Also can you see whether you can re-enable JdbcTest.testExplainJoin3 (which > is disabled due to OutOfMemoryError on Travis). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1671) Support for named bind parameters
Francis Chuang created CALCITE-1671:
---
Summary: Support for named bind parameters
Key: CALCITE-1671
URL: https://issues.apache.org/jira/browse/CALCITE-1671
Project: Calcite
Issue Type: New Feature
Reporter: Francis Chuang
Assignee: Julian Hyde
Priority: Minor
As discussed on the mailing list, there is some interest in supporting named
bind parameters:
{code}
SELECT * FROM my_table WHERE my_column > :parameter1 AND mycolumn2 > :parameter2
{code}
Will mixing of named and unnamed parameters be allowed?
{code}
SELECT * FROM my_table WHERE my_column > :parameter1 AND mycolumn2 > ? AND
mycolumn3 > :parameter3
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1671) Support for named bind parameters
[
https://issues.apache.org/jira/browse/CALCITE-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15898241#comment-15898241
]
Francis Chuang commented on CALCITE-1671:
-
The spec is quite "loose" as it defers to the underlying databases for
implementation. Any behavior it defines pertains to the client only. For Go 1.8
(where named parameteres are supported), the changes are here:
https://docs.google.com/document/d/1F778e7ZSNiSmbju3jsEWzShcb8lIO4kDyfKDNm4PNd8/edit
- It makes no recommendations for how parameters are embedded in SQL nor what
characters are allowed. Go has built in unicode support, so any character can
be used.
- It makes no recommendations for whether a parameter can be used more than
once.
- Parameters have both an ordinal and named value. If it has a name, then we
only use the name for parameter substitution. If the parameter is unnamed, then
use the ordinal position for substitution.
In terms of named bind parameters, driver implementers should:
- Use the `sql.Named("parameter", value)" when working with named parameters.
For example, as a user of the database/sql package and a given driver, you
would write the following:
{code}
db.ExecContext(ctx, `
delete from Invoice
where
TimeCreated < @end
and TimeCreated >= @start;`,
sql.Named("start", startTime),
sql.Named("end", endTime),
)
{code}
- Defer the placeholder value to the driver or database, for example using `?`
for ordinal values.
- If both named and ordinal values are used in a statement, named parameters
should be bound to named values and ordinal parameters should use ordinal
values.
- Drivers must add any symbol prefix to named parameters. The database/sql will
pass in something like "ID" or "Name" and the driver shoudl prepend the symbol
if required: ":NAME" or "@NAME".
- If the database does not support named parameters, return an error if they
are used.
> Support for named bind parameters
> -
>
> Key: CALCITE-1671
> URL: https://issues.apache.org/jira/browse/CALCITE-1671
> Project: Calcite
> Issue Type: New Feature
>Reporter: Francis Chuang
>Assignee: Julian Hyde
>Priority: Minor
>
> As discussed on the mailing list, there is some interest in supporting named
> bind parameters:
> {code}
> SELECT * FROM my_table WHERE my_column > :parameter1 AND mycolumn2 >
> :parameter2
> {code}
> Will mixing of named and unnamed parameters be allowed?
> {code}
> SELECT * FROM my_table WHERE my_column > :parameter1 AND mycolumn2 > ? AND
> mycolumn3 > :parameter3
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CALCITE-1677) 2 copies of avatica docs on the website
Francis Chuang created CALCITE-1677: --- Summary: 2 copies of avatica docs on the website Key: CALCITE-1677 URL: https://issues.apache.org/jira/browse/CALCITE-1677 Project: Calcite Issue Type: Bug Reporter: Francis Chuang Assignee: Julian Hyde There appears to be 2 different copies of the avatica docs on the website. For example, for the protobuf docs, there are 2 copies: - https://calcite.apache.org/avatica/docs/protobuf_reference.html - https://calcite.apache.org/docs/avatica_protobuf_reference.html The ones hosted directly at https://calcite.apache.org/docs do not appear to be identical to the ones at https://calcite.apache.org/avatica/docs. It might be better to 1 copy of the docs and point the links to them. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CALCITE-1353) first_frame_max_size in an ExecuteRequest should be an int32 in protobuf definitions.
[
https://issues.apache.org/jira/browse/CALCITE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15960229#comment-15960229
]
Francis Chuang commented on CALCITE-1353:
-
Thanks for fixing this one, Josh!
> first_frame_max_size in an ExecuteRequest should be an int32 in protobuf
> definitions.
> -
>
> Key: CALCITE-1353
> URL: https://issues.apache.org/jira/browse/CALCITE-1353
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Francis Chuang
>Assignee: Josh Elser
>Priority: Minor
> Fix For: avatica-1.10.0
>
>
> In the protobuf definition for {{ExecuteRequest}}, the
> {{first_frame_max_size}} parameter is typed as an {{uint64}}. See
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L130.
> For consistency, it should be an {{int32}}.
> Similar parameters relating to the frame size are all typed as {{int32}}.
> For a {{PrepareAndExecuteRequest}}, {{first_frame_max_size}} is a{{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L78
> For a {{FetchRequest}}, {{frame_max_size}} is a {{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L96
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16110005#comment-16110005 ] Francis Chuang commented on CALCITE-1240: - [~julianhyde] Thanks for organizing this! An empty repo is fine, I can push the existing code into the repo. Should I push the existing tags or should we only have the tags for when the code is part of the Apache foundation? I agree that the headers docs and other pieces will need to be updated. Is there an official list of things we should do before tagging the first release? > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1937) Web site for Avatica Go
[ https://issues.apache.org/jira/browse/CALCITE-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123227#comment-16123227 ] Francis Chuang commented on CALCITE-1937: - I've done the following: - Move documentation into go_client_reference.md under site/ - Create go_history.md under site/ - Reduced README.md to the barebones. See PR: https://github.com/apache/calcite-avatica-go/pull/2 Question: I've removed most references to Apache Phoenix. Is this a good idea? There may be some benefits of including references to Phoenix as there is no doubt people are searching for a Go Phoenix database/sql driver using their favorite search engine. Having no references to Phoenix reduces this visibility, although it prevents confusion between the Phoenix and Calcite projects. > Web site for Avatica Go > --- > > Key: CALCITE-1937 > URL: https://issues.apache.org/jira/browse/CALCITE-1937 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Reporter: Julian Hyde >Assignee: Francis Chuang > > Create a web site for calcite-avatica-go. > How about this: > * At run time, the pages should appear under http://calcite.apache.org/avatica > * The pages should be source-controlled under calcite-avatica-go/site, in > markdown format (same as calcite and avatica), and generated into svn using > similar trickery to calcite and avatica. > * Reduce the amount of content in > https://github.com/apache/calcite-avatica-go/blob/master/README.md. The > "documentation" stuff should move to under http://calcite.apache.org/avatica. > So the page will be mainly a re-direct to the Apache home page. Similar to > https://github.com/apache/calcite-avatica/blob/master/README.md, in fact. > * Add a go_history.md file. > Should avatica-go appear on http://calcite.apache.org/avatica/downloads, or > should it have its own download page? I think it probably the former. -- 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=16124449#comment-16124449 ] Francis Chuang commented on CALCITE-1938: - For Go libraries, building a binary out of a library isn't very useful. In Go, there is the concept of the GOPATH. It is an environment variable pointing to a folder where you store and work on your Go projects. GOPATH should contain the src/, pkg/ and bin/ folders. Projects are placed in `src/`, for example `src/github.com/apache/calcite-avatica-go`. Executables are placed in bin, and they are built by running `go install` in your project. Under `pkg/`, you'd find the package binaries. They are intermediate objects that are cached by the go tool. For example, if I run `go install` in `src/github.com/some-org/some-project` to build an executable, and that project imports a certain version of calcite-avatica-go, the calcite-avatica-go dependency will be built as `src/github.com/apache/calcite-avatica-go.a`. In Go, libraries are not shipped and built as binaries are they are not very useful. The built binaries under the pkg/ folder are only temporary objects cached by Go to improve build performance and they should be re-built during the compilation of an executable. The standard workflow is to use the dep tool or some third party dependency management tool. It will check out the source into the project's vendor directory, and if `go install` or `go build` is executed, it will build the final binary. >From my understand of maven and comparing with Go: - Go does not need the clean step, as running tests or building does not create temporary or binaries in the source tree. - To test, we run `go test $(go list ./... | grep -v /vendor/)`. All this does is tell the go tool to traverse the project for test files and execute them, but exclude anything in the vendor/ folder because they contain the source of our dependencies. - Go install is not meaningful for a library. If the project produced an executable, then `go install` can be used to build and place the binary into GOPATH/bin. However, since calcite-avatica-go is a library, and there is no main package in the code, it is not meaningful to build a binary. > 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=16124449#comment-16124449
]
Francis Chuang edited comment on CALCITE-1938 at 8/12/17 4:30 AM:
--
For Go libraries, building a binary out of a library isn't very useful.
In Go, there is the concept of the GOPATH. It is an environment variable
pointing to a folder where you store and work on your Go projects. GOPATH
should contain the src/, pkg/ and bin/ folders. Projects are placed in `src/`,
for example `src/github.com/apache/calcite-avatica-go`. Executables are placed
in bin, and they are built by running `go install` in your project. Under
`pkg/`, you'd find the package binaries. They are intermediate objects that are
cached by the go tool. For example, if I run `go install` in
`src/github.com/some-org/some-project` to build an executable, and that project
imports a certain version of calcite-avatica-go, the calcite-avatica-go
dependency will be built as `src/github.com/apache/calcite-avatica-go.a`.
In Go, libraries are not shipped and built as binaries are they are not very
useful. The built binaries under the pkg/ folder are only temporary objects
cached by Go to improve build performance and they should be re-built during
the compilation of an executable.
The standard workflow is to use the dep tool or some third party dependency
management tool. It will check out the source into the project's vendor
directory, and if `go install` or `go build` is executed, it will build the
final binary.
>From my understand of maven and comparing with Go:
- Go does not need the clean step, as running tests or building does not create
temporary or binaries in the source tree.
- To test, we run `go test $(go list ./... | grep -v /vendor/)`. All this does
is tell the go tool to traverse the project for test files and execute them,
but exclude anything in the vendor/ folder because they contain the source of
our dependencies.
- Go install is not meaningful for a library. If the project produced an
executable, then `go install` can be used to build and place the binary into
GOPATH/bin. However, since calcite-avatica-go is a library, and there is no
main package in the code, it is not meaningful to build a binary.
In terms of developer instructions:
If you want to contribute to the project:
- Fork it.
- Clone the official repo (github.com/apache/calcite-avatica-go) to
GOPATH/src/github.com/apache/calcite-avatica-go.
- Add your fork as a remote for in the cloned repo.
- Make changes, run tests using `go test`, commit and push to your fork.
- Merge on Github (if using apache gitbox), or have a committer fetch your
changes into a branch on the apache git repo and merge.
If you want to use the library in a project:
- Install the dep tool (https://github.com/golang/dep) by running go get -u
github.com/golang/dep/cmd/dep
- Run `dep ensure -add github.com/apache/calcite-avatica-go` in your
project's root.
- Use the library in your project by `import`ing it and using it:
{code}
import _ "github.com/apache/calcite-avatica-go"
func main(){
db := ...
}
{code}
was (Author: francischuang):
For Go libraries, building a binary out of a library isn't very useful.
In Go, there is the concept of the GOPATH. It is an environment variable
pointing to a folder where you store and work on your Go projects. GOPATH
should contain the src/, pkg/ and bin/ folders. Projects are placed in `src/`,
for example `src/github.com/apache/calcite-avatica-go`. Executables are placed
in bin, and they are built by running `go install` in your project. Under
`pkg/`, you'd find the package binaries. They are intermediate objects that are
cached by the go tool. For example, if I run `go install` in
`src/github.com/some-org/some-project` to build an executable, and that project
imports a certain version of calcite-avatica-go, the calcite-avatica-go
dependency will be built as `src/github.com/apache/calcite-avatica-go.a`.
In Go, libraries are not shipped and built as binaries are they are not very
useful. The built binaries under the pkg/ folder are only temporary objects
cached by Go to improve build performance and they should be re-built during
the compilation of an executable.
The standard workflow is to use the dep tool or some third party dependency
management tool. It will check out the source into the project's vendor
directory, and if `go install` or `go build` is executed, it will build the
final binary.
>From my understand of maven and comparing with Go:
- Go does not need the clean step, as running tests or building does not create
temporary or binaries in the source tree.
- To test, we run `go test $(go list ./... | grep -v /vendor/)`. All this does
is tell the go tool to traverse the project for test files and execute them,
but exclude anything in the vendor/ folder
[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=16124449#comment-16124449
]
Francis Chuang edited comment on CALCITE-1938 at 8/12/17 4:29 AM:
--
For Go libraries, building a binary out of a library isn't very useful.
In Go, there is the concept of the GOPATH. It is an environment variable
pointing to a folder where you store and work on your Go projects. GOPATH
should contain the src/, pkg/ and bin/ folders. Projects are placed in `src/`,
for example `src/github.com/apache/calcite-avatica-go`. Executables are placed
in bin, and they are built by running `go install` in your project. Under
`pkg/`, you'd find the package binaries. They are intermediate objects that are
cached by the go tool. For example, if I run `go install` in
`src/github.com/some-org/some-project` to build an executable, and that project
imports a certain version of calcite-avatica-go, the calcite-avatica-go
dependency will be built as `src/github.com/apache/calcite-avatica-go.a`.
In Go, libraries are not shipped and built as binaries are they are not very
useful. The built binaries under the pkg/ folder are only temporary objects
cached by Go to improve build performance and they should be re-built during
the compilation of an executable.
The standard workflow is to use the dep tool or some third party dependency
management tool. It will check out the source into the project's vendor
directory, and if `go install` or `go build` is executed, it will build the
final binary.
>From my understand of maven and comparing with Go:
- Go does not need the clean step, as running tests or building does not create
temporary or binaries in the source tree.
- To test, we run `go test $(go list ./... | grep -v /vendor/)`. All this does
is tell the go tool to traverse the project for test files and execute them,
but exclude anything in the vendor/ folder because they contain the source of
our dependencies.
- Go install is not meaningful for a library. If the project produced an
executable, then `go install` can be used to build and place the binary into
GOPATH/bin. However, since calcite-avatica-go is a library, and there is no
main package in the code, it is not meaningful to build a binary.
In terms of developer instructions:
If you want to contribute to the project:
- Fork it.
- Clone the official repo (github.com/apache/calcite-avatica-go) to
GOPATH/src/github.com/apache/calcite-avatica-go.
- Add your fork as a remote for in the cloned repo.
- Make changes, run tests using `go test`, commit and push to your fork.
- Merge on Github (if using apache gitbox), or have a committer fetch your
changes into a branch on the apache git repo and merge.
If you want to use the library in a project:
- Install the dep tool (https://github.com/golang/dep) by running go get -u
github.com/golang/dep/cmd/dep
- Run `dep ensure -add github.com/apache/calcite-avatica-go`.
- Use the library in your project by `import`ing it and using it:
{code}
import _ "github.com/apache/calcite-avatica-go"
func main(){
db := ...
}
{code}
was (Author: francischuang):
For Go libraries, building a binary out of a library isn't very useful.
In Go, there is the concept of the GOPATH. It is an environment variable
pointing to a folder where you store and work on your Go projects. GOPATH
should contain the src/, pkg/ and bin/ folders. Projects are placed in `src/`,
for example `src/github.com/apache/calcite-avatica-go`. Executables are placed
in bin, and they are built by running `go install` in your project. Under
`pkg/`, you'd find the package binaries. They are intermediate objects that are
cached by the go tool. For example, if I run `go install` in
`src/github.com/some-org/some-project` to build an executable, and that project
imports a certain version of calcite-avatica-go, the calcite-avatica-go
dependency will be built as `src/github.com/apache/calcite-avatica-go.a`.
In Go, libraries are not shipped and built as binaries are they are not very
useful. The built binaries under the pkg/ folder are only temporary objects
cached by Go to improve build performance and they should be re-built during
the compilation of an executable.
The standard workflow is to use the dep tool or some third party dependency
management tool. It will check out the source into the project's vendor
directory, and if `go install` or `go build` is executed, it will build the
final binary.
>From my understand of maven and comparing with Go:
- Go does not need the clean step, as running tests or building does not create
temporary or binaries in the source tree.
- To test, we run `go test $(go list ./... | grep -v /vendor/)`. All this does
is tell the go tool to traverse the project for test files and execute them,
but exclude anything in the vendor/ folder because they contain the
[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=16124449#comment-16124449
]
Francis Chuang edited comment on CALCITE-1938 at 8/12/17 4:52 AM:
--
For Go libraries, building a binary out of a library isn't very useful.
In Go, there is the concept of the GOPATH. It is an environment variable
pointing to a folder where you store and work on your Go projects. GOPATH
should contain the src/, pkg/ and bin/ folders. Projects are placed in `src/`,
for example `src/github.com/apache/calcite-avatica-go`. Executables are placed
in bin, and they are built by running `go install` in your project. Under
`pkg/`, you'd find the package binaries. They are intermediate objects that are
cached by the go tool. For example, if I run `go install` in
`src/github.com/some-org/some-project` to build an executable, and that project
imports a certain version of calcite-avatica-go, the calcite-avatica-go
dependency will be built as `src/github.com/apache/calcite-avatica-go.a`.
In Go, libraries are not shipped and built as binaries are they are not very
useful. The built binaries under the pkg/ folder are only temporary objects
cached by Go to improve build performance and they should be re-built during
the compilation of an executable.
The standard workflow is to use the dep tool or some third party dependency
management tool. It will check out the source into the project's vendor
directory, and if `go install` or `go build` is executed, it will build the
final binary.
>From my understand of maven and comparing with Go:
- Go does not need the clean step, as running tests or building does not create
temporary files or binaries in the source tree.
- To test, we run `go test $(go list ./... | grep -v /vendor/)`. All this does
is tell the go tool to traverse the project for test files and execute them,
but exclude anything in the vendor/ folder because they contain the source of
our dependencies.
- Go install is not meaningful for a library. If the project produced an
executable, then `go install` can be used to build and place the binary into
GOPATH/bin. However, since calcite-avatica-go is a library, and there is no
main package in the code, it is not meaningful to build a binary.
In terms of developer instructions:
If you want to contribute to the project:
- Fork it.
- Clone the official repo (github.com/apache/calcite-avatica-go) to
GOPATH/src/github.com/apache/calcite-avatica-go.
- Add your fork as a remote for in the cloned repo.
- Make changes, run tests using `go test`, commit and push to your fork.
- Merge on Github (if using apache gitbox), or have a committer fetch your
changes into a branch on the apache git repo and merge.
If you want to use the library in a project:
- Install the dep tool (https://github.com/golang/dep) by running go get -u
github.com/golang/dep/cmd/dep
- Run `dep ensure -add github.com/apache/calcite-avatica-go` in your
project's root.
- Use the library in your project by `import`ing it and using it:
{code}
import _ "github.com/apache/calcite-avatica-go"
func main(){
db := ...
}
{code}
was (Author: francischuang):
For Go libraries, building a binary out of a library isn't very useful.
In Go, there is the concept of the GOPATH. It is an environment variable
pointing to a folder where you store and work on your Go projects. GOPATH
should contain the src/, pkg/ and bin/ folders. Projects are placed in `src/`,
for example `src/github.com/apache/calcite-avatica-go`. Executables are placed
in bin, and they are built by running `go install` in your project. Under
`pkg/`, you'd find the package binaries. They are intermediate objects that are
cached by the go tool. For example, if I run `go install` in
`src/github.com/some-org/some-project` to build an executable, and that project
imports a certain version of calcite-avatica-go, the calcite-avatica-go
dependency will be built as `src/github.com/apache/calcite-avatica-go.a`.
In Go, libraries are not shipped and built as binaries are they are not very
useful. The built binaries under the pkg/ folder are only temporary objects
cached by Go to improve build performance and they should be re-built during
the compilation of an executable.
The standard workflow is to use the dep tool or some third party dependency
management tool. It will check out the source into the project's vendor
directory, and if `go install` or `go build` is executed, it will build the
final binary.
>From my understand of maven and comparing with Go:
- Go does not need the clean step, as running tests or building does not create
temporary or binaries in the source tree.
- To test, we run `go test $(go list ./... | grep -v /vendor/)`. All this does
is tell the go tool to traverse the project for test files and execute them,
but exclude anything in the vendor/
[jira] [Commented] (CALCITE-1937) Web site for Avatica Go
[ https://issues.apache.org/jira/browse/CALCITE-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16124458#comment-16124458 ] Francis Chuang commented on CALCITE-1937: - I've updated the web pages to include relevant information regarding Phoenix support. I also added a README under site/ stating that the files are symlinked by calcite-avatica and pushes should be done from that repository. > Web site for Avatica Go > --- > > Key: CALCITE-1937 > URL: https://issues.apache.org/jira/browse/CALCITE-1937 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Reporter: Julian Hyde >Assignee: Francis Chuang > > Create a web site for calcite-avatica-go. > How about this: > * At run time, the pages should appear under http://calcite.apache.org/avatica > * The pages should be source-controlled under calcite-avatica-go/site, in > markdown format (same as calcite and avatica), and generated into svn using > similar trickery to calcite and avatica. > * Reduce the amount of content in > https://github.com/apache/calcite-avatica-go/blob/master/README.md. The > "documentation" stuff should move to under http://calcite.apache.org/avatica. > So the page will be mainly a re-direct to the Apache home page. Similar to > https://github.com/apache/calcite-avatica/blob/master/README.md, in fact. > * Add a go_history.md file. > Should avatica-go appear on http://calcite.apache.org/avatica/downloads, or > should it have its own download page? I think it probably the former. -- 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=16124449#comment-16124449
]
Francis Chuang edited comment on CALCITE-1938 at 8/12/17 4:29 AM:
--
For Go libraries, building a binary out of a library isn't very useful.
In Go, there is the concept of the GOPATH. It is an environment variable
pointing to a folder where you store and work on your Go projects. GOPATH
should contain the src/, pkg/ and bin/ folders. Projects are placed in `src/`,
for example `src/github.com/apache/calcite-avatica-go`. Executables are placed
in bin, and they are built by running `go install` in your project. Under
`pkg/`, you'd find the package binaries. They are intermediate objects that are
cached by the go tool. For example, if I run `go install` in
`src/github.com/some-org/some-project` to build an executable, and that project
imports a certain version of calcite-avatica-go, the calcite-avatica-go
dependency will be built as `src/github.com/apache/calcite-avatica-go.a`.
In Go, libraries are not shipped and built as binaries are they are not very
useful. The built binaries under the pkg/ folder are only temporary objects
cached by Go to improve build performance and they should be re-built during
the compilation of an executable.
The standard workflow is to use the dep tool or some third party dependency
management tool. It will check out the source into the project's vendor
directory, and if `go install` or `go build` is executed, it will build the
final binary.
>From my understand of maven and comparing with Go:
- Go does not need the clean step, as running tests or building does not create
temporary or binaries in the source tree.
- To test, we run `go test $(go list ./... | grep -v /vendor/)`. All this does
is tell the go tool to traverse the project for test files and execute them,
but exclude anything in the vendor/ folder because they contain the source of
our dependencies.
- Go install is not meaningful for a library. If the project produced an
executable, then `go install` can be used to build and place the binary into
GOPATH/bin. However, since calcite-avatica-go is a library, and there is no
main package in the code, it is not meaningful to build a binary.
In terms of developer instructions:
If you want to contribute to the project:
- Fork it.
- Clone the official repo (github.com/apache/calcite-avatica-go) to
GOPATH/src/github.com/apache/calcite-avatica-go.
- Add your fork as a remote for in the cloned repo.
- Make changes, run tests using `go test`, commit and push to your fork.
- Merge on Github (if using apache gitbox), or have a committer fetch your
changes into a branch on the apache git repo and merge.
If you want to use the library in a project:
- Install the dep tool (https://github.com/golang/dep) by running go get -u
github.com/golang/dep/cmd/dep
- Run `dep ensure -add github.com/apache/calcite-avatica-go`.
- Use the library in your project by `import`ing it and using it:
{code:go}
import _ "github.com/apache/calcite-avatica-go"
func main(){
db := ...
}
{code}
was (Author: francischuang):
For Go libraries, building a binary out of a library isn't very useful.
In Go, there is the concept of the GOPATH. It is an environment variable
pointing to a folder where you store and work on your Go projects. GOPATH
should contain the src/, pkg/ and bin/ folders. Projects are placed in `src/`,
for example `src/github.com/apache/calcite-avatica-go`. Executables are placed
in bin, and they are built by running `go install` in your project. Under
`pkg/`, you'd find the package binaries. They are intermediate objects that are
cached by the go tool. For example, if I run `go install` in
`src/github.com/some-org/some-project` to build an executable, and that project
imports a certain version of calcite-avatica-go, the calcite-avatica-go
dependency will be built as `src/github.com/apache/calcite-avatica-go.a`.
In Go, libraries are not shipped and built as binaries are they are not very
useful. The built binaries under the pkg/ folder are only temporary objects
cached by Go to improve build performance and they should be re-built during
the compilation of an executable.
The standard workflow is to use the dep tool or some third party dependency
management tool. It will check out the source into the project's vendor
directory, and if `go install` or `go build` is executed, it will build the
final binary.
>From my understand of maven and comparing with Go:
- Go does not need the clean step, as running tests or building does not create
temporary or binaries in the source tree.
- To test, we run `go test $(go list ./... | grep -v /vendor/)`. All this does
is tell the go tool to traverse the project for test files and execute them,
but exclude anything in the vendor/ folder because they contain
[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=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] [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-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-1948) Publish avatica-hypersql, avatica-mysql and avatica-postgres to docker hub
[ https://issues.apache.org/jira/browse/CALCITE-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16129842#comment-16129842 ] Francis Chuang commented on CALCITE-1948: - I see. That makes sense. If HyperSQL isn't a problem, I think it would be nice to have a HyperSQL image up on docker hub so that client maintainers can easily test against it. > Publish avatica-hypersql, avatica-mysql and avatica-postgres to docker hub > -- > > Key: CALCITE-1948 > URL: https://issues.apache.org/jira/browse/CALCITE-1948 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Francis Chuang >Assignee: Josh Elser > > I am currently making a port of the tests in calcite-avatica-go to test > against the calcite-avatica image in docker hub. > Unfortunately, the calcite-avatica image only includes the avatica-server, > which makes it difficult to stand up a test environment. > It would be nice if the docker images for HyperSQL, MySQL and Postgres can be > published as well. > This can be achieved by configuring docker hub's automatic build to look in > the appropriate subfolders for the dockerfile and push tags with the > appropriate backing db, for example 1.10.0-hypersql, 1.10.0-mysql etc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1950) Avatica HSQLDB docker image hangs
[ https://issues.apache.org/jira/browse/CALCITE-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16129958#comment-16129958 ] Francis Chuang commented on CALCITE-1950: - Some further info. It seems the server starts to hang once I run a test to test optimistic currency. The test current hangs: - `CREATE TABLE some_table (id INTEGER PRIMARY KEY, msg VARCHAR,version INTEGER)` - Prepare statement1: `INSERT INTO some_table (id, msg, version) VALUES(?, ?, ?)` - Insert 6 rows using statement1. - Start tx1 - Start tx2 - Using tx1, `SELECT MAX(version) FROM some_table` - Using tx2, `INSERT INTO some_table (id, msg, version) VALUES(?, ?, ?)`. At this point, it seems the server starts to hang and I am unable to perform any further operations. > Avatica HSQLDB docker image hangs > - > > Key: CALCITE-1950 > URL: https://issues.apache.org/jira/browse/CALCITE-1950 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Francis Chuang >Assignee: Josh Elser > > I am using the calcite-avatica hsqldb image here: > https://hub.docker.com/r/f21global/calcite-avatica/ > The image is built using this docker file: > https://github.com/apache/calcite-avatica/tree/master/docker/src/main/docker/hypersql > I am currently running integration tests for the Go client against that > image. It seems that after a certain amount of operations, the server will > lock up. From the Go http client, it seems that avatica no longer responds. > There wasn't any interesting information when I ran `docker logs` on the > container avatica/hsqldb is running in. > When it starts hanging, tests that were passing previously would fail > randomly, because the test is not able to get a response form avatica. > Usually, deleting and recreating the container would resolve the problem, but > after using the same container through a few more test cycles, it starts to > hang again. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1950) Avatica HSQLDB docker image hangs
Francis Chuang created CALCITE-1950: --- Summary: Avatica HSQLDB docker image hangs Key: CALCITE-1950 URL: https://issues.apache.org/jira/browse/CALCITE-1950 Project: Calcite Issue Type: Bug Components: avatica Reporter: Francis Chuang Assignee: Josh Elser I am using the calcite-avatica hsqldb image here: https://hub.docker.com/r/f21global/calcite-avatica/ The image is built using this docker file: https://github.com/apache/calcite-avatica/tree/master/docker/src/main/docker/hypersql I am currently running integration tests for the Go client against that image. It seems that after a certain amount of operations, the server will lock up. From the Go http client, it seems that avatica no longer responds. There wasn't any interesting information when I ran `docker logs` on the container avatica/hsqldb is running in. When it starts hanging, tests that were passing previously would fail randomly, because the test is not able to get a response form avatica. Usually, deleting and recreating the container would resolve the problem, but after using the same container through a few more test cycles, it starts to hang again. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1948) Publish avatica-hypersql, avatica-mysql and avatica-postgres to docker hub
Francis Chuang created CALCITE-1948: --- Summary: Publish avatica-hypersql, avatica-mysql and avatica-postgres to docker hub Key: CALCITE-1948 URL: https://issues.apache.org/jira/browse/CALCITE-1948 Project: Calcite Issue Type: Improvement Components: avatica Reporter: Francis Chuang Assignee: Josh Elser I am currently making a port of the tests in calcite-avatica-go to test against the calcite-avatica image in docker hub. Unfortunately, the calcite-avatica image only includes the avatica-server, which makes it difficult to stand up a test environment. It would be nice if the docker images for HyperSQL, MySQL and Postgres can be published as well. This can be achieved by configuring docker hub's automatic build to look in the appropriate subfolders for the dockerfile and push tags with the appropriate backing db, for example 1.10.0-hypersql, 1.10.0-mysql etc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1951) Avatica HSQLDB docker image time loses fractional seconds
Francis Chuang created CALCITE-1951:
---
Summary: Avatica HSQLDB docker image time loses fractional seconds
Key: CALCITE-1951
URL: https://issues.apache.org/jira/browse/CALCITE-1951
Project: Calcite
Issue Type: Bug
Components: avatica
Reporter: Francis Chuang
Assignee: Josh Elser
I create a table like so in HSQLDB using the avatica-hsqldb image:
{code}
CREATE TABLE some_table (
tm TIME(6) PRIMARY KEY,
)
{code}
I then use calculate the milliseconds since 00:00:00.000 and send this value
along with my insert statement: 76881222
However, when I select the row to read the value back, I get 76881000.
In this case, 222 milliseconds was lost.
--
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=16130281#comment-16130281 ] Francis Chuang commented on CALCITE-1938: - Just a quick update on what I've been working on. I've added an environment variable called AVATICA_FLAVOR for running tests. You'd set it to HSQLDB to run tests against the calcite-avatica-hsqldb image and PHOENIX to run tests against phoenix. These tests can be run in parallel using a build matrix on Travis or pipelines in Wercker. I've ported most of the Phoenix tests over but there are a few failing that I haven't had time to investigate. There are a few where I believe relates to bugs in the hsqldb image and JIRAs have been opened for them. How do you guys feel about using gitbox (https://gitbox.apache.org) for the calcite-avatica-go repo? This will allow merging PRs on Github and perhaps we can just use Travis or Wercker for CI and forego having to use jenkins on ASF infra. > 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=16122813#comment-16122813 ] Francis Chuang commented on CALCITE-1938: - Thanks for opening this, Julian. I think we should use this JIRA to deal with the things we need to do to make the first release. Here are the things I feel must be completed before a first release can be tagged: * Switch CI to Apache Jenkins * Use self-hosted coverage reporting tool (maybe sonarqube's golang plugin) * Remove dependency on go-cleanhttp * Create release history page After release: * Update URL in the awesome-go list I think setting up CI should be something we make a move on first as that might require coordination with INFRA. Are you able to get the ball rolling for this one? > 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=16122851#comment-16122851 ] Francis Chuang commented on CALCITE-1938: - Yea, I think 2.2.0 would be good for the first Apache release. That makes sense. > 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-1937) Web site for Avatica Go
[ https://issues.apache.org/jira/browse/CALCITE-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16122852#comment-16122852 ] Francis Chuang commented on CALCITE-1937: - I think this should be a low hanging fruit. I'll check out how this is done in the calcite and calcite-avatica repos and start working on a branch. > Web site for Avatica Go > --- > > Key: CALCITE-1937 > URL: https://issues.apache.org/jira/browse/CALCITE-1937 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Reporter: Julian Hyde >Assignee: Francis Chuang > > Create a web site for calcite-avatica-go. > How about this: > * At run time, the pages should appear under http://calcite.apache.org/avatica > * The pages should be source-controlled under calcite-avatica-go/site, in > markdown format (same as calcite and avatica), and generated into svn using > similar trickery to calcite and avatica. > * Reduce the amount of content in > https://github.com/apache/calcite-avatica-go/blob/master/README.md. The > "documentation" stuff should move to under http://calcite.apache.org/avatica. > So the page will be mainly a re-direct to the Apache home page. Similar to > https://github.com/apache/calcite-avatica/blob/master/README.md, in fact. > * Add a go_history.md file. > Should avatica-go appear on http://calcite.apache.org/avatica/downloads, or > should it have its own download page? I think it probably the former. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1937) Web site for Avatica Go
[ https://issues.apache.org/jira/browse/CALCITE-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16122861#comment-16122861 ] Francis Chuang commented on CALCITE-1937: - [~julianhyde]Does it make sense if I just copy the file tree from calcite-avatica/site into calcite-avatica-go/site and replace the files inside _docs with my own markdown documents? > Web site for Avatica Go > --- > > Key: CALCITE-1937 > URL: https://issues.apache.org/jira/browse/CALCITE-1937 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Reporter: Julian Hyde >Assignee: Francis Chuang > > Create a web site for calcite-avatica-go. > How about this: > * At run time, the pages should appear under http://calcite.apache.org/avatica > * The pages should be source-controlled under calcite-avatica-go/site, in > markdown format (same as calcite and avatica), and generated into svn using > similar trickery to calcite and avatica. > * Reduce the amount of content in > https://github.com/apache/calcite-avatica-go/blob/master/README.md. The > "documentation" stuff should move to under http://calcite.apache.org/avatica. > So the page will be mainly a re-direct to the Apache home page. Similar to > https://github.com/apache/calcite-avatica/blob/master/README.md, in fact. > * Add a go_history.md file. > Should avatica-go appear on http://calcite.apache.org/avatica/downloads, or > should it have its own download page? I think it probably the former. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1937) Web site for Avatica Go
[ https://issues.apache.org/jira/browse/CALCITE-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16122861#comment-16122861 ] Francis Chuang edited comment on CALCITE-1937 at 8/11/17 5:17 AM: -- -[~julianhyde]Does it make sense if I just copy the file tree from calcite-avatica/site into calcite-avatica-go/site and replace the files inside _docs with my own markdown documents?- Ok, that makes sense too. I am assuming I'd just need to write the markdown files and chuck them in my `site` folder then. was (Author: francischuang): [~julianhyde]Does it make sense if I just copy the file tree from calcite-avatica/site into calcite-avatica-go/site and replace the files inside _docs with my own markdown documents? > Web site for Avatica Go > --- > > Key: CALCITE-1937 > URL: https://issues.apache.org/jira/browse/CALCITE-1937 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Reporter: Julian Hyde >Assignee: Francis Chuang > > Create a web site for calcite-avatica-go. > How about this: > * At run time, the pages should appear under http://calcite.apache.org/avatica > * The pages should be source-controlled under calcite-avatica-go/site, in > markdown format (same as calcite and avatica), and generated into svn using > similar trickery to calcite and avatica. > * Reduce the amount of content in > https://github.com/apache/calcite-avatica-go/blob/master/README.md. The > "documentation" stuff should move to under http://calcite.apache.org/avatica. > So the page will be mainly a re-direct to the Apache home page. Similar to > https://github.com/apache/calcite-avatica/blob/master/README.md, in fact. > * Add a go_history.md file. > Should avatica-go appear on http://calcite.apache.org/avatica/downloads, or > should it have its own download page? I think it probably the former. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16095516#comment-16095516 ] Francis Chuang edited comment on CALCITE-1240 at 7/20/17 11:03 PM: --- For the dependencies: Other than Go's standard library, the project also imports the following dependencies directly: https://github.com/Boostport/avatica/blob/master/Gopkg.toml The imported dependencies also import further dependencies of their own. The list of ALL dependencies used are in here: https://github.com/Boostport/avatica/blob/master/Gopkg.lock Dependencies under the golang.org/x/ namespace are part of the Go project but are considered to be experimental. was (Author: francischuang): For the dependencies: Other than Go's standard library, the project also imports the following dependencies directly: https://github.com/Boostport/avatica/blob/master/Gopkg.toml The imported dependencies also imports further dependencies of their own. The list of ALL dependencies used are in here: https://github.com/Boostport/avatica/blob/master/Gopkg.lock Dependencies under the golang.org/x/ namespace are part of the Go project but are considered to be experimental. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16095590#comment-16095590 ] Francis Chuang commented on CALCITE-1240: - go-cleanhttp is a really simple library. All it does is set up the http client with sane defaults: https://github.com/hashicorp/go-cleanhttp/blob/master/cleanhttp.go If required, I can remove the dependency on it and initialize the http client manually with those defaults. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16093971#comment-16093971 ] Francis Chuang commented on CALCITE-1240: - [~julianhyde] A few questions: 1. What is the process for getting the code into the Calcite/Avatica project? 2. Is it possible to get a separate git repo for this? It makes it easier to import using Go's dependency tools like dep and the package structure would be more idiomatic. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16118054#comment-16118054 ] Francis Chuang edited comment on CALCITE-1240 at 8/8/17 8:54 AM: - Ok, the repo is now on Github, but I ran into a snag as I am not allowed to push directly to apache/calcite-avatica-go on github. - The repo is currently empty, so I cannot fork it on GH and use a fork. - I created a F21/calcite-avatica-go repo and pushed the initial commit there, but it won't let me open a PR against apache/calcite-avatica-go. was (Author: francischuang): Ok, the repo is now on Github, but I ran into a snag as I am not allowed to push directly to apache/calcite-avatica-go. - The repo is currently empty, so I cannot fork it on GH and use a fork. - I created a F21/calcite-avatica-go repo and pushed the initial commit there, but it won't let me open a PR against apache/calcite-avatica-go. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16118054#comment-16118054 ] Francis Chuang edited comment on CALCITE-1240 at 8/8/17 8:57 AM: - Ok, the repo is now on Github, but I ran into a snag as I am not allowed to push directly to apache/calcite-avatica-go on github. - The repo is currently empty, so I cannot fork it on GH and use a fork. - I created a F21/calcite-avatica-go repo and pushed the initial commit there, but it won't let me open a PR against apache/calcite-avatica-go. A few other issues: - I currently use Wercker for CI. Can wercker be used on Apache repos? - I use goveralls for code coverage reports. Can it be used on Apache repos? was (Author: francischuang): Ok, the repo is now on Github, but I ran into a snag as I am not allowed to push directly to apache/calcite-avatica-go on github. - The repo is currently empty, so I cannot fork it on GH and use a fork. - I created a F21/calcite-avatica-go repo and pushed the initial commit there, but it won't let me open a PR against apache/calcite-avatica-go. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16118054#comment-16118054 ] Francis Chuang commented on CALCITE-1240: - Ok, the repo is now on Github, but I ran into a snag as I am not allowed to push directly to apache/calcite-avatica-go. - The repo is currently empty, so I cannot fork it on GH and use a fork. - I created a F21/calcite-avatica-go repo and pushed the initial commit there, but it won't let me open a PR against apache/calcite-avatica-go. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119260#comment-16119260 ] Francis Chuang edited comment on CALCITE-1240 at 8/9/17 1:00 AM: - [~elserj]Thanks for sorting that out! [~elserj][~julianhyde] A PR has been opened on the GH repo to rack the initial commit. There are still a few things to do before it can be merged. Regarding tags, should tags from the original repo be pushed? Or should be start a new versioning scheme? was (Author: francischuang): [~elserj]Thanks for sorting that out! [~elserj][~julianhyde] A PR has been opened on the GH repo to rack the initial commit. There are still a few things to do before it can be merged. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119260#comment-16119260 ] Francis Chuang commented on CALCITE-1240: - [~elserj]Thanks for sorting that out! [~elserj][~julianhyde] A PR has been opened on the GH repo to rack the initial commit. There are still a few things to do before it can be merged. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119358#comment-16119358 ] Francis Chuang commented on CALCITE-1240: - I did some research regarding using Apache's infrastructure for CI and the ASF buildbot. I have some questions regarding how to set this up: - What needs to be done to set up CI for the project? - Can Apache's Jenkins build PRs submitted on github as well? - Jenkins uses a jenkinsfile which is stored in the project repo, but I do not see the jenkinsfile in the calcite or kafka repos. How are builds configured? There is a sonarqube instance: https://wiki.apache.org/general/SonarInstance Maybe it can provide code coverage, but I think the Go plugin needs to be installed: https://github.com/uartois/sonar-golang Ideally, there should be build status and coverage status images that can be embedded in the README.md file. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119358#comment-16119358 ] Francis Chuang edited comment on CALCITE-1240 at 8/9/17 3:30 AM: - I did some research regarding using Apache's infrastructure for CI and the ASF buildbot. I have some questions regarding how to set this up: - What needs to be done to set up CI for the project? - Can Apache's Jenkins build PRs submitted on github as well? - Jenkins uses a jenkinsfile which is stored in the project repo, but I do not see the jenkinsfile in the calcite or kafka repos. How are builds configured? There is a sonarqube instance: https://wiki.apache.org/general/SonarInstance Maybe it can provide code coverage, but I think the Go plugin needs to be installed: https://github.com/uartois/sonar-golang Ideally, there should be build status and coverage status images that can be embedded in the README.md file. Regarding github pushes, I think it may be possible if the repo is hosted on Gitbox: https://gitbox.apache.org was (Author: francischuang): I did some research regarding using Apache's infrastructure for CI and the ASF buildbot. I have some questions regarding how to set this up: - What needs to be done to set up CI for the project? - Can Apache's Jenkins build PRs submitted on github as well? - Jenkins uses a jenkinsfile which is stored in the project repo, but I do not see the jenkinsfile in the calcite or kafka repos. How are builds configured? There is a sonarqube instance: https://wiki.apache.org/general/SonarInstance Maybe it can provide code coverage, but I think the Go plugin needs to be installed: https://github.com/uartois/sonar-golang Ideally, there should be build status and coverage status images that can be embedded in the README.md file. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120894#comment-16120894 ] Francis Chuang commented on CALCITE-1240: - I've added the Apache License header to the files. I will probably not add the pre-Apache tags, as the original boostport/avatica repo will still be around for those using the old import path (there will be a message in the README directing people to the new repo). Here's the current todo list: * Create release history page * Switch CI to Apache Jenkins * Use self-hosted coverage reporting tool (maybe sonarqube's golang plugin) * Update URL in the awesome-go list * Update driver description on Avatica website > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120990#comment-16120990 ] Francis Chuang edited comment on CALCITE-1240 at 8/10/17 3:22 AM: -- Hey [~julianhyde] Thanks for the comments. I added the header to wercker.yml, but I am not sure how to add the header to .gitignore. See the following in the calcite repo: https://github.com/apache/calcite/blob/master/.gitignore Gopkg.lock is a file generated by dep (https://github.com/golang/dep). It is poised to become the official package manager for Go. This file must be committed as it contains the exact commit hashes of the dependencies installed. The Gopkg.toml file only contains the constraints, for example, use the minor versions of a dependency that is versioned at 1.2.1. Therefore, the lock file is required for reproducible builds. It is equivalent to the lock file used by NPM 5. The vendor directory contains dependencies used by the calcite-avatica-go library. When running tests, libraries and projects do not run tests in the vendor directory. The vendored dependencies should have their own tests and the owner of the dependencies should be testing them. It does not make any sense to build the library. The library should be add into a project using dep, which will copy it to the project's vendor directory. On compilation, Go will build a single static binary for the project. I've pushed updated the PR with changes to the readme and a license header to wercker.yml. was (Author: francischuang): Hey [~julianhyde] Thanks for the comments. I added the header to wercker.yml, but I am not sure how to add the header to README.md and .gitignore. See the following in the calcite repo: https://github.com/apache/calcite/blob/master/README and https://github.com/apache/calcite/blob/master/.gitignore Gopkg.lock is a file generated by dep (https://github.com/golang/dep). It is poised to become the official package manager for Go. This file must be committed as it contains the exact commit hashes of the dependencies installed. The Gopkg.toml file only contains the constraints, for example, use the minor versions of a dependency that is versioned at 1.2.1. Therefore, the lock file is required for reproducible builds. It is equivalent to the lock file used by NPM 5. The vendor directory contains dependencies used by the calcite-avatica-go library. When running tests, libraries and projects do not run tests in the vendor directory. The vendored dependencies should have their own tests and the owner of the dependencies should be testing them. It does not make any sense to build the library. The library should be add into a project using dep, which will copy it to the project's vendor directory. On compilation, Go will build a single static binary for the project. I've pushed updated the PR with changes to the readme and a license header to wercker.yml. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120990#comment-16120990 ] Francis Chuang commented on CALCITE-1240: - Hey [~julianhyde] Thanks for the comments. I added the header to wercker.yml, but I am not sure how to add the header to README.md and .gitignore. See the following in the calcite repo: https://github.com/apache/calcite/blob/master/README and https://github.com/apache/calcite/blob/master/.gitignore Gopkg.lock is a file generated by dep (https://github.com/golang/dep). It is poised to become the official package manager for Go. This file must be committed as it contains the exact commit hashes of the dependencies installed. The Gopkg.toml file only contains the constraints for example the minor version of a dependency that is versioned at 1.2.1. Therefore, the lock file is required for reproducible builds. It is equivalent to the lock file used by NPM 5. The vendor directory contains dependencies used by the calcite-avatica-go library. When running tests, libraries and projects to not run tests in the vendor directory. The vendored dependencies should have their own tests and the owner of the dependencies should be testing them. It does not make any sense to build the library. The library should be add into a project using dep, which will copy it to the project's vendor directory. On compilation, Go will build a single static binary for the project. I've pushed updated the PR with changes to the readme and a license header to wercker.yml. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120990#comment-16120990 ] Francis Chuang edited comment on CALCITE-1240 at 8/10/17 3:20 AM: -- Hey [~julianhyde] Thanks for the comments. I added the header to wercker.yml, but I am not sure how to add the header to README.md and .gitignore. See the following in the calcite repo: https://github.com/apache/calcite/blob/master/README and https://github.com/apache/calcite/blob/master/.gitignore Gopkg.lock is a file generated by dep (https://github.com/golang/dep). It is poised to become the official package manager for Go. This file must be committed as it contains the exact commit hashes of the dependencies installed. The Gopkg.toml file only contains the constraints, for example, use the minor versions of a dependency that is versioned at 1.2.1. Therefore, the lock file is required for reproducible builds. It is equivalent to the lock file used by NPM 5. The vendor directory contains dependencies used by the calcite-avatica-go library. When running tests, libraries and projects to not run tests in the vendor directory. The vendored dependencies should have their own tests and the owner of the dependencies should be testing them. It does not make any sense to build the library. The library should be add into a project using dep, which will copy it to the project's vendor directory. On compilation, Go will build a single static binary for the project. I've pushed updated the PR with changes to the readme and a license header to wercker.yml. was (Author: francischuang): Hey [~julianhyde] Thanks for the comments. I added the header to wercker.yml, but I am not sure how to add the header to README.md and .gitignore. See the following in the calcite repo: https://github.com/apache/calcite/blob/master/README and https://github.com/apache/calcite/blob/master/.gitignore Gopkg.lock is a file generated by dep (https://github.com/golang/dep). It is poised to become the official package manager for Go. This file must be committed as it contains the exact commit hashes of the dependencies installed. The Gopkg.toml file only contains the constraints for example the minor version of a dependency that is versioned at 1.2.1. Therefore, the lock file is required for reproducible builds. It is equivalent to the lock file used by NPM 5. The vendor directory contains dependencies used by the calcite-avatica-go library. When running tests, libraries and projects to not run tests in the vendor directory. The vendored dependencies should have their own tests and the owner of the dependencies should be testing them. It does not make any sense to build the library. The library should be add into a project using dep, which will copy it to the project's vendor directory. On compilation, Go will build a single static binary for the project. I've pushed updated the PR with changes to the readme and a license header to wercker.yml. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120990#comment-16120990 ] Francis Chuang edited comment on CALCITE-1240 at 8/10/17 3:31 AM: -- Hey [~julianhyde] Thanks for the comments. I added the header to wercker.yml, but I am not sure how to add the header to .gitignore. See the following in the calcite repo: https://github.com/apache/calcite/blob/master/.gitignore Gopkg.lock is a file generated by dep (https://github.com/golang/dep). It is poised to become the official package manager for Go. This file must be committed as it contains the exact commit hashes of the dependencies installed. The Gopkg.toml file only contains the constraints, for example, use the minor versions of a dependency that is versioned at 1.2.1. Therefore, the lock file is required for reproducible builds. It is equivalent to the lock file used by NPM 5. The vendor directory is a standard go-specific folder that contains dependencies used by the go projects. See https://golang.org/cmd/go/#hdr-Vendor_Directories When running tests, libraries and projects do not run tests in the vendor directory. The vendored dependencies should have their own tests and the owner of the dependencies should be testing them. It does not make any sense to build the library. The library should be add into a project using dep, which will copy it to the project's vendor directory. On compilation, Go will build a single static binary for the project. I've pushed updated the PR with changes to the readme and a license header to wercker.yml. was (Author: francischuang): Hey [~julianhyde] Thanks for the comments. I added the header to wercker.yml, but I am not sure how to add the header to .gitignore. See the following in the calcite repo: https://github.com/apache/calcite/blob/master/.gitignore Gopkg.lock is a file generated by dep (https://github.com/golang/dep). It is poised to become the official package manager for Go. This file must be committed as it contains the exact commit hashes of the dependencies installed. The Gopkg.toml file only contains the constraints, for example, use the minor versions of a dependency that is versioned at 1.2.1. Therefore, the lock file is required for reproducible builds. It is equivalent to the lock file used by NPM 5. The vendor directory is a standard go-specific folder that contains dependencies used by the go projects. When running tests, libraries and projects do not run tests in the vendor directory. The vendored dependencies should have their own tests and the owner of the dependencies should be testing them. It does not make any sense to build the library. The library should be add into a project using dep, which will copy it to the project's vendor directory. On compilation, Go will build a single static binary for the project. I've pushed updated the PR with changes to the readme and a license header to wercker.yml. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120990#comment-16120990 ] Francis Chuang edited comment on CALCITE-1240 at 8/10/17 3:30 AM: -- Hey [~julianhyde] Thanks for the comments. I added the header to wercker.yml, but I am not sure how to add the header to .gitignore. See the following in the calcite repo: https://github.com/apache/calcite/blob/master/.gitignore Gopkg.lock is a file generated by dep (https://github.com/golang/dep). It is poised to become the official package manager for Go. This file must be committed as it contains the exact commit hashes of the dependencies installed. The Gopkg.toml file only contains the constraints, for example, use the minor versions of a dependency that is versioned at 1.2.1. Therefore, the lock file is required for reproducible builds. It is equivalent to the lock file used by NPM 5. The vendor directory is a standard go-specific folder that contains dependencies used by the go projects. When running tests, libraries and projects do not run tests in the vendor directory. The vendored dependencies should have their own tests and the owner of the dependencies should be testing them. It does not make any sense to build the library. The library should be add into a project using dep, which will copy it to the project's vendor directory. On compilation, Go will build a single static binary for the project. I've pushed updated the PR with changes to the readme and a license header to wercker.yml. was (Author: francischuang): Hey [~julianhyde] Thanks for the comments. I added the header to wercker.yml, but I am not sure how to add the header to .gitignore. See the following in the calcite repo: https://github.com/apache/calcite/blob/master/.gitignore Gopkg.lock is a file generated by dep (https://github.com/golang/dep). It is poised to become the official package manager for Go. This file must be committed as it contains the exact commit hashes of the dependencies installed. The Gopkg.toml file only contains the constraints, for example, use the minor versions of a dependency that is versioned at 1.2.1. Therefore, the lock file is required for reproducible builds. It is equivalent to the lock file used by NPM 5. The vendor directory is a standard go-specific folder that contains dependencies used by the calcite-avatica-go library. When running tests, libraries and projects do not run tests in the vendor directory. The vendored dependencies should have their own tests and the owner of the dependencies should be testing them. It does not make any sense to build the library. The library should be add into a project using dep, which will copy it to the project's vendor directory. On compilation, Go will build a single static binary for the project. I've pushed updated the PR with changes to the readme and a license header to wercker.yml. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120990#comment-16120990 ] Francis Chuang edited comment on CALCITE-1240 at 8/10/17 3:30 AM: -- Hey [~julianhyde] Thanks for the comments. I added the header to wercker.yml, but I am not sure how to add the header to .gitignore. See the following in the calcite repo: https://github.com/apache/calcite/blob/master/.gitignore Gopkg.lock is a file generated by dep (https://github.com/golang/dep). It is poised to become the official package manager for Go. This file must be committed as it contains the exact commit hashes of the dependencies installed. The Gopkg.toml file only contains the constraints, for example, use the minor versions of a dependency that is versioned at 1.2.1. Therefore, the lock file is required for reproducible builds. It is equivalent to the lock file used by NPM 5. The vendor directory is a standard go-specific folder that contains dependencies used by the calcite-avatica-go library. When running tests, libraries and projects do not run tests in the vendor directory. The vendored dependencies should have their own tests and the owner of the dependencies should be testing them. It does not make any sense to build the library. The library should be add into a project using dep, which will copy it to the project's vendor directory. On compilation, Go will build a single static binary for the project. I've pushed updated the PR with changes to the readme and a license header to wercker.yml. was (Author: francischuang): Hey [~julianhyde] Thanks for the comments. I added the header to wercker.yml, but I am not sure how to add the header to .gitignore. See the following in the calcite repo: https://github.com/apache/calcite/blob/master/.gitignore Gopkg.lock is a file generated by dep (https://github.com/golang/dep). It is poised to become the official package manager for Go. This file must be committed as it contains the exact commit hashes of the dependencies installed. The Gopkg.toml file only contains the constraints, for example, use the minor versions of a dependency that is versioned at 1.2.1. Therefore, the lock file is required for reproducible builds. It is equivalent to the lock file used by NPM 5. The vendor directory contains dependencies used by the calcite-avatica-go library. When running tests, libraries and projects do not run tests in the vendor directory. The vendored dependencies should have their own tests and the owner of the dependencies should be testing them. It does not make any sense to build the library. The library should be add into a project using dep, which will copy it to the project's vendor directory. On compilation, Go will build a single static binary for the project. I've pushed updated the PR with changes to the readme and a license header to wercker.yml. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120990#comment-16120990 ] Francis Chuang edited comment on CALCITE-1240 at 8/10/17 3:31 AM: -- Hey [~julianhyde] Thanks for the comments. I added the header to wercker.yml, but I am not sure how to add the header to .gitignore. See the following in the calcite repo: https://github.com/apache/calcite/blob/master/.gitignore The Gopkg.lock is a file generated by dep (https://github.com/golang/dep). It is poised to become the official package manager for Go. This file must be committed as it contains the exact commit hashes of the dependencies installed. The Gopkg.toml file only contains the constraints, for example, use the minor versions of a dependency that is versioned at 1.2.1. Therefore, the lock file is required for reproducible builds. It is equivalent to the lock file used by NPM 5. The vendor directory is a standard go-specific folder that contains dependencies used by the go projects. See https://golang.org/cmd/go/#hdr-Vendor_Directories When running tests, libraries and projects do not run tests in the vendor directory. The vendored dependencies should have their own tests and the owner of the dependencies should be testing them. It does not make any sense to build the library. The library should be add into a project using dep, which will copy it to the project's vendor directory. On compilation, Go will build a single static binary for the project. I've pushed updated the PR with changes to the readme and a license header to wercker.yml. was (Author: francischuang): Hey [~julianhyde] Thanks for the comments. I added the header to wercker.yml, but I am not sure how to add the header to .gitignore. See the following in the calcite repo: https://github.com/apache/calcite/blob/master/.gitignore Gopkg.lock is a file generated by dep (https://github.com/golang/dep). It is poised to become the official package manager for Go. This file must be committed as it contains the exact commit hashes of the dependencies installed. The Gopkg.toml file only contains the constraints, for example, use the minor versions of a dependency that is versioned at 1.2.1. Therefore, the lock file is required for reproducible builds. It is equivalent to the lock file used by NPM 5. The vendor directory is a standard go-specific folder that contains dependencies used by the go projects. See https://golang.org/cmd/go/#hdr-Vendor_Directories When running tests, libraries and projects do not run tests in the vendor directory. The vendored dependencies should have their own tests and the owner of the dependencies should be testing them. It does not make any sense to build the library. The library should be add into a project using dep, which will copy it to the project's vendor directory. On compilation, Go will build a single static binary for the project. I've pushed updated the PR with changes to the readme and a license header to wercker.yml. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120990#comment-16120990 ] Francis Chuang edited comment on CALCITE-1240 at 8/10/17 3:33 AM: -- Hey [~julianhyde] Thanks for the comments. I added the header to wercker.yml and readme.md, but I am not sure how to add the header to .gitignore. See the following in the calcite repo: https://github.com/apache/calcite/blob/master/.gitignore The Gopkg.lock is a file generated by dep (https://github.com/golang/dep). It is poised to become the official package manager for Go. This file must be committed as it contains the exact commit hashes of the dependencies installed. The Gopkg.toml file only contains the constraints, for example, use the minor versions of a dependency that is versioned at 1.2.1. Therefore, the lock file is required for reproducible builds. It is equivalent to the lock file used by NPM 5. The vendor directory is a standard go-specific folder that contains dependencies used by the go projects. See https://golang.org/cmd/go/#hdr-Vendor_Directories When running tests, libraries and projects do not run tests in the vendor directory. The vendored dependencies should have their own tests and the owner of the dependencies should be testing them. It does not make any sense to build Go libraries into a binary. The library should be add into a project using dep, which will checkout the source to the project's vendor directory. On compilation, Go will build a single static binary for the project. I've pushed updated the PR with changes to the readme and a license header to wercker.yml. was (Author: francischuang): Hey [~julianhyde] Thanks for the comments. I added the header to wercker.yml and readme.md, but I am not sure how to add the header to .gitignore. See the following in the calcite repo: https://github.com/apache/calcite/blob/master/.gitignore The Gopkg.lock is a file generated by dep (https://github.com/golang/dep). It is poised to become the official package manager for Go. This file must be committed as it contains the exact commit hashes of the dependencies installed. The Gopkg.toml file only contains the constraints, for example, use the minor versions of a dependency that is versioned at 1.2.1. Therefore, the lock file is required for reproducible builds. It is equivalent to the lock file used by NPM 5. The vendor directory is a standard go-specific folder that contains dependencies used by the go projects. See https://golang.org/cmd/go/#hdr-Vendor_Directories When running tests, libraries and projects do not run tests in the vendor directory. The vendored dependencies should have their own tests and the owner of the dependencies should be testing them. It does not make any sense to build Go libraries into a binary. The library should be add into a project using dep, which will copy it to the project's vendor directory. On compilation, Go will build a single static binary for the project. I've pushed updated the PR with changes to the readme and a license header to wercker.yml. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120990#comment-16120990 ] Francis Chuang edited comment on CALCITE-1240 at 8/10/17 3:33 AM: -- Hey [~julianhyde] Thanks for the comments. I added the header to wercker.yml and readme.md, but I am not sure how to add the header to .gitignore. See the following in the calcite repo: https://github.com/apache/calcite/blob/master/.gitignore The Gopkg.lock is a file generated by dep (https://github.com/golang/dep). It is poised to become the official package manager for Go. This file must be committed as it contains the exact commit hashes of the dependencies installed. The Gopkg.toml file only contains the constraints, for example, use the minor versions of a dependency that is versioned at 1.2.1. Therefore, the lock file is required for reproducible builds. It is equivalent to the lock file used by NPM 5. The vendor directory is a standard go-specific folder that contains dependencies used by the go projects. See https://golang.org/cmd/go/#hdr-Vendor_Directories When running tests, libraries and projects do not run tests in the vendor directory. The vendored dependencies should have their own tests and the owner of the dependencies should be testing them. It does not make any sense to build Go libraries into a binary. The library should be add into a project using dep, which will copy it to the project's vendor directory. On compilation, Go will build a single static binary for the project. I've pushed updated the PR with changes to the readme and a license header to wercker.yml. was (Author: francischuang): Hey [~julianhyde] Thanks for the comments. I added the header to wercker.yml and readme.md, but I am not sure how to add the header to .gitignore. See the following in the calcite repo: https://github.com/apache/calcite/blob/master/.gitignore The Gopkg.lock is a file generated by dep (https://github.com/golang/dep). It is poised to become the official package manager for Go. This file must be committed as it contains the exact commit hashes of the dependencies installed. The Gopkg.toml file only contains the constraints, for example, use the minor versions of a dependency that is versioned at 1.2.1. Therefore, the lock file is required for reproducible builds. It is equivalent to the lock file used by NPM 5. The vendor directory is a standard go-specific folder that contains dependencies used by the go projects. See https://golang.org/cmd/go/#hdr-Vendor_Directories When running tests, libraries and projects do not run tests in the vendor directory. The vendored dependencies should have their own tests and the owner of the dependencies should be testing them. It does not make any sense to build the library. The library should be add into a project using dep, which will copy it to the project's vendor directory. On compilation, Go will build a single static binary for the project. I've pushed updated the PR with changes to the readme and a license header to wercker.yml. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116311#comment-16116311 ] Francis Chuang commented on CALCITE-1240: - Also, I can't find the avatica-go repo in the Apache org on github. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16104348#comment-16104348 ] Francis Chuang commented on CALCITE-1240: - Hey [~julianhyde] Thanks for getting the ball rolling. A corporate CLA for Boostport Pty Ltd was signed in September last year when I was accepted as a committer. An acknowledgement was CC'd to the calcite private list on the 6th of September, 2016. Is this sufficient? If not, I'll fill in the Software Grant Agreement and send that to secret...@apache.org Using the current HEAD should be fine. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116173#comment-16116173 ] Francis Chuang commented on CALCITE-1240: - [~julianhyde]Should I push the whole commit history from the old repo, or just the latest commit (without the history)? > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1951) Avatica HSQLDB docker image time loses fractional seconds
[
https://issues.apache.org/jira/browse/CALCITE-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16131444#comment-16131444
]
Francis Chuang commented on CALCITE-1951:
-
This is the current test that is running against Phoenix and passes:
https://github.com/apache/calcite-avatica-go/blob/master/driver_test.go#L392
This is the test (simplied) against HSQLDB that demonstrates this problem:
{code}
func TestHSQLDBLocations(t *testing.T) {
query := "?location=Australia/Melbourne"
runTests(t, dsn+query, func(dbt *DBTest) {
// Create and seed table
dbt.mustExec(`CREATE TABLE ` + dbt.tableName + ` (
tm TIME(6) PRIMARY KEY,
dt DATE,
tmstmp TIMESTAMP
)`)
loc, err := time.LoadLocation("Australia/Melbourne")
if err != nil {
dbt.Fatalf("Unexpected error: %s", err)
}
var (
tmValue time.Time = time.Date(0, 1, 1, 21, 21, 21,
22200, loc)
dtValue time.Time = time.Date(2100, 2, 1, 0, 0, 0,
0, loc)
tmstmpValue time.Time = time.Date(2100, 2, 1, 21, 21,
21, 22200, loc)
)
dbt.mustExec(`INSERT INTO `+dbt.tableName+`(tm, dt, tmstmp)
VALUES (?, ?, ?)`,
tmValue,
dtValue,
tmstmpValue,
)
rows := dbt.mustQuery("SELECT * FROM " + dbt.tableName)
defer rows.Close()
var (
tm time.Time
dt time.Time
tmstmp time.Time
)
for rows.Next() {
err := rows.Scan(, , )
if err != nil {
dbt.Fatal(err)
}
}
comparisons := []struct {
result time.Time
expected time.Time
}{
{tm, tmValue},
{dt, dtValue},
{tmstmp, tmstmpValue},
}
for _, tt := range comparisons {
if !tt.result.Equal(tt.expected) {
dbt.Errorf("Expected %v, got %v.", tt.expected,
tt.result)
}
}
})
}
{code}
The comparison for date and timestamp works correctly. However, the comparison
for time fails as the selected value loses the fractional seconds.
According to the guide on data types
(http://hsqldb.org/doc/2.0/guide/sqlgeneral-chapt.html#sgc_data_type_guide),
defining a field as TIME(6) should have 6 fractional seconds for the field. By
default it is 0, but I've set it to 6 in my table definition.
> Avatica HSQLDB docker image time loses fractional seconds
> -
>
> Key: CALCITE-1951
> URL: https://issues.apache.org/jira/browse/CALCITE-1951
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Francis Chuang
>Assignee: Josh Elser
>
> I create a table like so in HSQLDB using the avatica-hsqldb image:
> {code}
> CREATE TABLE some_table (
> tm TIME(6) PRIMARY KEY,
> )
> {code}
> I then use calculate the milliseconds since 00:00:00.000 and send this value
> along with my insert statement: 76881222
> However, when I select the row to read the value back, I get 76881000.
> In this case, 222 milliseconds was lost.
--
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=16131434#comment-16131434
]
Francis Chuang commented on CALCITE-1938:
-
{quote}
Is Gitbox a requirement for using Travis/Wercker? Calcite and Avatica already
use Travis..
{quote}
No it's not. However, I believe enabling Gitbox turns the Github repo into the
"source of truth". Currently, you'd need Jenkis for CI to run tests on the
master branch of the ASF repo. However, Jenkins is not able to run tests for
PRs on Github. However, if Github becomes the source of truth via Gitbox, then
we could just use Travis/Wercker, etc to run tests on Github's master branch
and any PRs.
> 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-1955) Cannot insert blob into Avatica-HSQLDB table because table is read only
[
https://issues.apache.org/jira/browse/CALCITE-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16133898#comment-16133898
]
Francis Chuang commented on CALCITE-1955:
-
>From my understanding of the HSQLDB docs, I think if the data set is loaded
>using res: LOBs are not writable. Another option would be to switch on an
>environment variable. For example, if USE_DATASET=true, load the scott
>dataset, otherwise default to memory.
> Cannot insert blob into Avatica-HSQLDB table because table is read only
> ---
>
> Key: CALCITE-1955
> URL: https://issues.apache.org/jira/browse/CALCITE-1955
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Francis Chuang
>
> This might be more of a question as I am not able to find official
> information in the HSQLDB docs.
> I am porting a test to test the insertion of binary data into a table from
> Phoenix to HSQLDB. The test passes when using Phoenix with avatica.
> 1. I created this table:
> {code}
> CREATE TABLE some_table (
> int INTEGER PRIMARY KEY,
> bin BLOB
> )
> {code}
> 2. I attempt to insert the data using `INSERT INTO some_table (int, bin)
> VALUES (?, ?)`
> The binary is being sent as a `Rep_BYTE_STRING` and the data is placed in
> byte_values.
> This is the error I receive from HSQLDB:
> {code}
> RuntimeException: java.sql.SQLException: org.hsqldb.HsqlException: The table
> data is read only -> SQLException: org.hsqldb.HsqlException: The table data
> is read only -> HsqlException: org.hsqldb.HsqlException: The table data is
> read only -> HsqlException: The table data is read only
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
