[jira] [Created] (CALCITE-1210) Cassandra uuid filtering does not work

2016-04-20 Thread Dan Di Spaltro (JIRA) 
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

2016-04-20 Thread Francis Chuang (JIRA) 
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

2016-04-20 Thread Julian Hyde (JIRA) 

[ 
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)