[jira] [Created] (CALCITE-1210) Cassandra uuid filtering does not work
Dan Di Spaltro created CALCITE-1210: --- Summary: Cassandra uuid filtering does not work Key: CALCITE-1210 URL: https://issues.apache.org/jira/browse/CALCITE-1210 Project: Calcite Issue Type: Bug Affects Versions: 1.7.0 Reporter: Dan Di Spaltro Assignee: Julian Hyde Priority: Minor It looks like the syntax for sending a uuid to cassandra is something like this {code} select key from timetest where key=7daecb80-29b0-11e3-92ec-e291eb9d325e {code} Which is a bare identifier, unquoted. So any filtering based on uuid's doesn't work. You get something like this: {code} Caused by: com.datastax.driver.core.exceptions.InvalidQueryException: Invalid STRING constant (a594f989-8e73-4145-b9fb-83bd565f9995) for "tweet_id" of type uuid` ... {code} -- 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] [Commented] (CALCITE-1150) Create the a new DynamicRecordType, avoiding star expansion when working with this type
[ https://issues.apache.org/jira/browse/CALCITE-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15250601#comment-15250601 ] Julian Hyde commented on CALCITE-1150: -- This feature will be useful, and as I have said to [~jnadeau] would fit well within Calcite, but it’s a bit shapeless to me right now. I would like to see some validator tests (any maybe one or two sql-to-rel converter tests) so I get a feel for how it would work. When you have some tests can you post a link to the github branch? I don’t think you should charge ahead with the implementation because I might not agree with the specification (i.e. the test cases). > Create the a new DynamicRecordType, avoiding star expansion when working with > this type > --- > > Key: CALCITE-1150 > URL: https://issues.apache.org/jira/browse/CALCITE-1150 > Project: Calcite > Issue Type: Improvement >Reporter: Jacques Nadeau >Assignee: Julian Hyde > > DynamicRecordType can be used to leverage user-provided field implications to > avoid schema analysis until execution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)