[jira] [Commented] (CASSANDRA-6151) CqlPagingRecorderReader Used when Partition Key Is Explicitly Stated
[
https://issues.apache.org/jira/browse/CASSANDRA-6151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806823#comment-13806823
]
Chad Johnston commented on CASSANDRA-6151:
--
Everything seems to be working as expected now.
> CqlPagingRecorderReader Used when Partition Key Is Explicitly Stated
>
>
> Key: CASSANDRA-6151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6151
> Project: Cassandra
> Issue Type: Bug
> Components: Hadoop
>Reporter: Russell Alexander Spitzer
>Assignee: Alex Liu
>Priority: Minor
> Attachments: 6151-1.2-branch.txt, 6151-v2-1.2-branch.txt,
> 6151-v3-1.2-branch.txt
>
>
> From
> http://stackoverflow.com/questions/19189649/composite-key-in-cassandra-with-pig/19211546#19211546
> The user was attempting to load a single partition using a where clause in a
> pig load statement.
> CQL Table
> {code}
> CREATE table data (
> occurday text,
> seqnumber int,
> occurtimems bigint,
> unique bigint,
> fields map,
> primary key ((occurday, seqnumber), occurtimems, unique)
> )
> {code}
> Pig Load statement Query
> {code}
> data = LOAD
> 'cql://ks/data?where_clause=seqnumber%3D10%20AND%20occurday%3D%272013-10-01%27'
> USING CqlStorage();
> {code}
> This results in an exception when processed by the the CqlPagingRecordReader
> which attempts to page this query even though it contains at most one
> partition key. This leads to an invalid CQL statement.
> CqlPagingRecordReader Query
> {code}
> SELECT * FROM "data" WHERE token("occurday","seqnumber") > ? AND
> token("occurday","seqnumber") <= ? AND occurday='A Great Day'
> AND seqnumber=1 LIMIT 1000 ALLOW FILTERING
> {code}
> Exception
> {code}
> InvalidRequestException(why:occurday cannot be restricted by more than one
> relation if it includes an Equal)
> {code}
> I'm not sure it is worth the special case but, a modification to not use the
> paging record reader when the entire partition key is specified would solve
> this issue.
> h3. Solution
> If it have EQUAL clauses for all the partitioning keys, we use Query
> {code}
> SELECT * FROM "data"
> WHERE occurday='A Great Day'
>AND seqnumber=1 LIMIT 1000 ALLOW FILTERING
> {code}
> instead of
> {code}
> SELECT * FROM "data"
> WHERE token("occurday","seqnumber") > ?
>AND token("occurday","seqnumber") <= ?
>AND occurday='A Great Day'
>AND seqnumber=1 LIMIT 1000 ALLOW FILTERING
> {code}
> The base line implementation is to retrieve all data of all rows around the
> ring. This new feature is to retrieve all data of a wide row. It's a one
> level lower than the base line. It helps for the use case where user is only
> interested in a specific wide row, so the user doesn't spend whole job to
> retrieve all the rows around the ring.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-6151) CqlPagingRecorderReader Used when Partition Key Is Explicitly Stated
[
https://issues.apache.org/jira/browse/CASSANDRA-6151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13805622#comment-13805622
]
Chad Johnston commented on CASSANDRA-6151:
--
Okay - I re-cloned the repo and applied the patch again. All of the
{{pig-test}} tests pass, but I still get "keyspace does not exist" from within
Pig.
> CqlPagingRecorderReader Used when Partition Key Is Explicitly Stated
>
>
> Key: CASSANDRA-6151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6151
> Project: Cassandra
> Issue Type: Bug
> Components: Hadoop
>Reporter: Russell Alexander Spitzer
>Assignee: Alex Liu
>Priority: Minor
> Attachments: 6151-1.2-branch.txt, 6151-v2-1.2-branch.txt
>
>
> From
> http://stackoverflow.com/questions/19189649/composite-key-in-cassandra-with-pig/19211546#19211546
> The user was attempting to load a single partition using a where clause in a
> pig load statement.
> CQL Table
> {code}
> CREATE table data (
> occurday text,
> seqnumber int,
> occurtimems bigint,
> unique bigint,
> fields map,
> primary key ((occurday, seqnumber), occurtimems, unique)
> )
> {code}
> Pig Load statement Query
> {code}
> data = LOAD
> 'cql://ks/data?where_clause=seqnumber%3D10%20AND%20occurday%3D%272013-10-01%27'
> USING CqlStorage();
> {code}
> This results in an exception when processed by the the CqlPagingRecordReader
> which attempts to page this query even though it contains at most one
> partition key. This leads to an invalid CQL statement.
> CqlPagingRecordReader Query
> {code}
> SELECT * FROM "data" WHERE token("occurday","seqnumber") > ? AND
> token("occurday","seqnumber") <= ? AND occurday='A Great Day'
> AND seqnumber=1 LIMIT 1000 ALLOW FILTERING
> {code}
> Exception
> {code}
> InvalidRequestException(why:occurday cannot be restricted by more than one
> relation if it includes an Equal)
> {code}
> I'm not sure it is worth the special case but, a modification to not use the
> paging record reader when the entire partition key is specified would solve
> this issue.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-6151) CqlPagingRecorderReader Used when Partition Key Is Explicitly Stated
[
https://issues.apache.org/jira/browse/CASSANDRA-6151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13805541#comment-13805541
]
Chad Johnston commented on CASSANDRA-6151:
--
I still get the "keyspace does not exist" error. This makes me wonder if I have
something wrong in my environment. Is there a way I can turn on some debugging
or other diagnostics?
> CqlPagingRecorderReader Used when Partition Key Is Explicitly Stated
>
>
> Key: CASSANDRA-6151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6151
> Project: Cassandra
> Issue Type: Bug
> Components: Hadoop
>Reporter: Russell Alexander Spitzer
>Assignee: Alex Liu
>Priority: Minor
> Attachments: 6151-1.2-branch.txt, 6151-v2-1.2-branch.txt
>
>
> From
> http://stackoverflow.com/questions/19189649/composite-key-in-cassandra-with-pig/19211546#19211546
> The user was attempting to load a single partition using a where clause in a
> pig load statement.
> CQL Table
> {code}
> CREATE table data (
> occurday text,
> seqnumber int,
> occurtimems bigint,
> unique bigint,
> fields map,
> primary key ((occurday, seqnumber), occurtimems, unique)
> )
> {code}
> Pig Load statement Query
> {code}
> data = LOAD
> 'cql://ks/data?where_clause=seqnumber%3D10%20AND%20occurday%3D%272013-10-01%27'
> USING CqlStorage();
> {code}
> This results in an exception when processed by the the CqlPagingRecordReader
> which attempts to page this query even though it contains at most one
> partition key. This leads to an invalid CQL statement.
> CqlPagingRecordReader Query
> {code}
> SELECT * FROM "data" WHERE token("occurday","seqnumber") > ? AND
> token("occurday","seqnumber") <= ? AND occurday='A Great Day'
> AND seqnumber=1 LIMIT 1000 ALLOW FILTERING
> {code}
> Exception
> {code}
> InvalidRequestException(why:occurday cannot be restricted by more than one
> relation if it includes an Equal)
> {code}
> I'm not sure it is worth the special case but, a modification to not use the
> paging record reader when the entire partition key is specified would solve
> this issue.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-6151) CqlPagingRecorderReader Used when Partition Key Is Explicitly Stated
[
https://issues.apache.org/jira/browse/CASSANDRA-6151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13805460#comment-13805460
]
Chad Johnston commented on CASSANDRA-6151:
--
That works around the consistency error. I still get the error saying the
keyspace was not found whenever I specify a {{where_clause}}.
> CqlPagingRecorderReader Used when Partition Key Is Explicitly Stated
>
>
> Key: CASSANDRA-6151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6151
> Project: Cassandra
> Issue Type: Bug
> Components: Hadoop
>Reporter: Russell Alexander Spitzer
>Assignee: Alex Liu
>Priority: Minor
> Attachments: 6151-1.2-branch.txt
>
>
> From
> http://stackoverflow.com/questions/19189649/composite-key-in-cassandra-with-pig/19211546#19211546
> The user was attempting to load a single partition using a where clause in a
> pig load statement.
> CQL Table
> {code}
> CREATE table data (
> occurday text,
> seqnumber int,
> occurtimems bigint,
> unique bigint,
> fields map,
> primary key ((occurday, seqnumber), occurtimems, unique)
> )
> {code}
> Pig Load statement Query
> {code}
> data = LOAD
> 'cql://ks/data?where_clause=seqnumber%3D10%20AND%20occurday%3D%272013-10-01%27'
> USING CqlStorage();
> {code}
> This results in an exception when processed by the the CqlPagingRecordReader
> which attempts to page this query even though it contains at most one
> partition key. This leads to an invalid CQL statement.
> CqlPagingRecordReader Query
> {code}
> SELECT * FROM "data" WHERE token("occurday","seqnumber") > ? AND
> token("occurday","seqnumber") <= ? AND occurday='A Great Day'
> AND seqnumber=1 LIMIT 1000 ALLOW FILTERING
> {code}
> Exception
> {code}
> InvalidRequestException(why:occurday cannot be restricted by more than one
> relation if it includes an Equal)
> {code}
> I'm not sure it is worth the special case but, a modification to not use the
> paging record reader when the entire partition key is specified would solve
> this issue.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-6151) CqlPagingRecorderReader Used when Partition Key Is Explicitly Stated
[
https://issues.apache.org/jira/browse/CASSANDRA-6151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13805437#comment-13805437
]
Chad Johnston commented on CASSANDRA-6151:
--
I'm having issues running my tests against the 1.2 branch. If I give a {{load}}
statement with no {{where_clause}}, I get the error "{{consistency level
LOCAL_ONE not compatible with replication strategy
(org.apache.cassandra.locator.SimpleStrategy)}}".
When I try the query with the {{where_clause}}, I get an error saying that the
keyspace does not exist, even though I can query the keyspace with no issues in
cqlsh.
> CqlPagingRecorderReader Used when Partition Key Is Explicitly Stated
>
>
> Key: CASSANDRA-6151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6151
> Project: Cassandra
> Issue Type: Bug
> Components: Hadoop
>Reporter: Russell Alexander Spitzer
>Assignee: Alex Liu
>Priority: Minor
> Attachments: 6151-1.2-branch.txt
>
>
> From
> http://stackoverflow.com/questions/19189649/composite-key-in-cassandra-with-pig/19211546#19211546
> The user was attempting to load a single partition using a where clause in a
> pig load statement.
> CQL Table
> {code}
> CREATE table data (
> occurday text,
> seqnumber int,
> occurtimems bigint,
> unique bigint,
> fields map,
> primary key ((occurday, seqnumber), occurtimems, unique)
> )
> {code}
> Pig Load statement Query
> {code}
> data = LOAD
> 'cql://ks/data?where_clause=seqnumber%3D10%20AND%20occurday%3D%272013-10-01%27'
> USING CqlStorage();
> {code}
> This results in an exception when processed by the the CqlPagingRecordReader
> which attempts to page this query even though it contains at most one
> partition key. This leads to an invalid CQL statement.
> CqlPagingRecordReader Query
> {code}
> SELECT * FROM "data" WHERE token("occurday","seqnumber") > ? AND
> token("occurday","seqnumber") <= ? AND occurday='A Great Day'
> AND seqnumber=1 LIMIT 1000 ALLOW FILTERING
> {code}
> Exception
> {code}
> InvalidRequestException(why:occurday cannot be restricted by more than one
> relation if it includes an Equal)
> {code}
> I'm not sure it is worth the special case but, a modification to not use the
> paging record reader when the entire partition key is specified would solve
> this issue.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-6083) Pig requires explicit cast from int to long to save to Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13805416#comment-13805416 ] Chad Johnston commented on CASSANDRA-6083: -- I am unable to reproduce this in 1.2.10 or 1.2.11. I don't know what I ran into before, but I can't make it happen again. > Pig requires explicit cast from int to long to save to Cassandra > > > Key: CASSANDRA-6083 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6083 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Reporter: Chad Johnston >Assignee: Alex Liu >Priority: Minor > > Since version 1.2.10, I have to manually cast any int values in Pig to long > in order to store them into bigint Cassandra columns. I did not have to > perform this cast in previous versions of Cassandra. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6083) Pig requires explicit cast from int to long to save to Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13804748#comment-13804748 ] Chad Johnston commented on CASSANDRA-6083: -- I ran into the issue when loading a file from disk and saving it into Cassandra. I'll put together a reproducible case. There's a small chance that this was fixed with the changes for https://issues.apache.org/jira/browse/CASSANDRA-6102. I'll generate my test case against 1.2.10 and see if it's still an issue in 1.2.11. > Pig requires explicit cast from int to long to save to Cassandra > > > Key: CASSANDRA-6083 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6083 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Reporter: Chad Johnston >Assignee: Alex Liu >Priority: Minor > > Since version 1.2.10, I have to manually cast any int values in Pig to long > in order to store them into bigint Cassandra columns. I did not have to > perform this cast in previous versions of Cassandra. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6151) CqlPagingRecorderReader Used when Partition Key Is Explicitly Stated
[
https://issues.apache.org/jira/browse/CASSANDRA-6151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803341#comment-13803341
]
Chad Johnston commented on CASSANDRA-6151:
--
Alex - I'll try to get to it in the next day or so.
> CqlPagingRecorderReader Used when Partition Key Is Explicitly Stated
>
>
> Key: CASSANDRA-6151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6151
> Project: Cassandra
> Issue Type: Bug
> Components: Hadoop
>Reporter: Russell Alexander Spitzer
>Assignee: Alex Liu
>Priority: Minor
> Attachments: 6151-1.2-branch.txt
>
>
> From
> http://stackoverflow.com/questions/19189649/composite-key-in-cassandra-with-pig/19211546#19211546
> The user was attempting to load a single partition using a where clause in a
> pig load statement.
> CQL Table
> {code}
> CREATE table data (
> occurday text,
> seqnumber int,
> occurtimems bigint,
> unique bigint,
> fields map,
> primary key ((occurday, seqnumber), occurtimems, unique)
> )
> {code}
> Pig Load statement Query
> {code}
> data = LOAD
> 'cql://ks/data?where_clause=seqnumber%3D10%20AND%20occurday%3D%272013-10-01%27'
> USING CqlStorage();
> {code}
> This results in an exception when processed by the the CqlPagingRecordReader
> which attempts to page this query even though it contains at most one
> partition key. This leads to an invalid CQL statement.
> CqlPagingRecordReader Query
> {code}
> SELECT * FROM "data" WHERE token("occurday","seqnumber") > ? AND
> token("occurday","seqnumber") <= ? AND occurday='A Great Day'
> AND seqnumber=1 LIMIT 1000 ALLOW FILTERING
> {code}
> Exception
> {code}
> InvalidRequestException(why:occurday cannot be restricted by more than one
> relation if it includes an Equal)
> {code}
> I'm not sure it is worth the special case but, a modification to not use the
> paging record reader when the entire partition key is specified would solve
> this issue.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-6151) CqlPagingRecorderReader Used when Partition Key Is Explicitly Stated
[
https://issues.apache.org/jira/browse/CASSANDRA-6151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797290#comment-13797290
]
Chad Johnston commented on CASSANDRA-6151:
--
For what it's worth, our use case involves looking up data mostly by
{{occurday}}, since we're partitioning by day. Leaving off {{seqnumber}} from
the query isn't allowed, hence my example of a single value. In reality, we'd
really want to use {{IN()}} for {{seqnumber}} but that fails as well.
> CqlPagingRecorderReader Used when Partition Key Is Explicitly Stated
>
>
> Key: CASSANDRA-6151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6151
> Project: Cassandra
> Issue Type: Bug
> Components: Hadoop
>Reporter: Russell Alexander Spitzer
>Assignee: Alex Liu
>Priority: Minor
>
> From
> http://stackoverflow.com/questions/19189649/composite-key-in-cassandra-with-pig/19211546#19211546
> The user was attempting to load a single partition using a where clause in a
> pig load statement.
> CQL Table
> {code}
> CREATE table data (
> occurday text,
> seqnumber int,
> occurtimems bigint,
> unique bigint,
> fields map,
> primary key ((occurday, seqnumber), occurtimems, unique)
> )
> {code}
> Pig Load statement Query
> {code}
> data = LOAD
> 'cql://ks/data?where_clause=seqnumber%3D10%20AND%20occurday%3D%272013-10-01%27'
> USING CqlStorage();
> {code}
> This results in an exception when processed by the the CqlPagingRecordReader
> which attempts to page this query even though it contains at most one
> partition key. This leads to an invalid CQL statement.
> CqlPagingRecordReader Query
> {code}
> SELECT * FROM "data" WHERE token("occurday","seqnumber") > ? AND
> token("occurday","seqnumber") <= ? AND occurday='A Great Day'
> AND seqnumber=1 LIMIT 1000 ALLOW FILTERING
> {code}
> Exception
> {code}
> InvalidRequestException(why:occurday cannot be restricted by more than one
> relation if it includes an Equal)
> {code}
> I'm not sure it is worth the special case but, a modification to not use the
> paging record reader when the entire partition key is specified would solve
> this issue.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-6096) Look into a Pig Macro to url encode URLs passed to CqlStorage
[
https://issues.apache.org/jira/browse/CASSANDRA-6096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13777999#comment-13777999
]
Chad Johnston commented on CASSANDRA-6096:
--
I think a UDF is probably the best way to go. Dynamically invoking URLEncoder
doesn't seem to work as expected. I'd hoped to be able to say something like
{code}
STORE data INTO UrlEncode('cql://keyspace/table?update_query=set foo = ?',
'UTF-8') USING CqlStorage();
{code}
but I get an error saying that the next token after "INTO" is expected to be "
' ". I created a macro but I get the same results due to the way macros are
expanded inline.
The other issue with using URLEncoder dynamically is that it will encode the
entire CQL query. I don't know if this is desirable or not.
> Look into a Pig Macro to url encode URLs passed to CqlStorage
> -
>
> Key: CASSANDRA-6096
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6096
> Project: Cassandra
> Issue Type: Bug
> Components: Hadoop
>Reporter: Jeremy Hanna
>Priority: Minor
>
> In the evolution of CqlStorage, the URL went from non-encoded to encoded. It
> would be great to somehow keep the URL readable, perhaps using the Pig macro
> interface to do expansion:
> http://pig.apache.org/docs/r0.9.2/cont.html#macros
> See also CASSANDRA-6073 and CASSANDRA-5867
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-6073) Changes for Pig collections break CQL prepared statements
[ https://issues.apache.org/jira/browse/CASSANDRA-6073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13777613#comment-13777613 ] Chad Johnston commented on CASSANDRA-6073: -- What Keith is saying is that the CQL prepared statement interface changed pretty significantly between 1.2.9 and 1.2.10, and that it's generally very uncommon for such a change to happen between minor version numbers. I'm also interested to see some discussion about the "official" level of support for Pig. It really does feel second class. > Changes for Pig collections break CQL prepared statements > - > > Key: CASSANDRA-6073 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6073 > Project: Cassandra > Issue Type: Bug > Components: Hadoop > Environment: 1.2.10-tentative branch >Reporter: Chad Johnston >Assignee: Alex Liu > > I've checked out and built the 1.2.10-tentative branch, and I've noticed that > all of my CQL prepared statements are now broken. > Looking into the code, it looks like the "#" -> "=" and "@" -> "?" > translations were removed. I tried to replace these in one of my scripts with > "=" and "?", but there's other code that splits the query string on "=", > causing the prepared statement to be malformed. > If I look at the comments on > https://issues.apache.org/jira/browse/CASSANDRA-5867, where this change was > made, I see a single mention of URL encoding the CQL query. Is this the > expectation going forward? Was there a reason that the "#" and "@" mappings > were removed? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-6073) Changes for Pig collections break CQL prepared statements
[ https://issues.apache.org/jira/browse/CASSANDRA-6073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13774782#comment-13774782 ] Chad Johnston commented on CASSANDRA-6073: -- Is this change documented anywhere? I only lucked onto it by digging into the comments of CASSANDRA-5867. This has the side effect of requiring us to change all of our existing Pig scripts that use CqlStorage for saving into Cassandra, and the URL encoding greatly reduces readability of the Pig script. > Changes for Pig collections break CQL prepared statements > - > > Key: CASSANDRA-6073 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6073 > Project: Cassandra > Issue Type: Bug > Components: Hadoop > Environment: 1.2.10-tentative branch >Reporter: Chad Johnston >Assignee: Alex Liu > > I've checked out and built the 1.2.10-tentative branch, and I've noticed that > all of my CQL prepared statements are now broken. > Looking into the code, it looks like the "#" -> "=" and "@" -> "?" > translations were removed. I tried to replace these in one of my scripts with > "=" and "?", but there's other code that splits the query string on "=", > causing the prepared statement to be malformed. > If I look at the comments on > https://issues.apache.org/jira/browse/CASSANDRA-5867, where this change was > made, I see a single mention of URL encoding the CQL query. Is this the > expectation going forward? Was there a reason that the "#" and "@" mappings > were removed? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-6073) Changes for Pig collections break CQL prepared statements
[ https://issues.apache.org/jira/browse/CASSANDRA-6073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chad Johnston updated CASSANDRA-6073: - Description: I've checked out and built the 1.2.10-tentative branch, and I've noticed that all of my CQL prepared statements are now broken. Looking into the code, it looks like the "#" -> "=" and "@" -> "?" translations were removed. I tried to replace these in one of my scripts with "=" and "?", but there's other code that splits the query string on "=", causing the prepared statement to be malformed. If I look at the comments on https://issues.apache.org/jira/browse/CASSANDRA-5867, where this change was made, I see a single mention of URL encoding the CQL query. Is this the expectation going forward? Was there a reason that the "#" and "@" mappings were removed? was: I've checked out and built the 1.2.10-tentative branch, and I've noticed that all of my CQL prepared statements are now broken. Looking into the code, it looks like the "#" -> "=" and "@" -> "?" translations were removed. I tried to replace these in one of my scripts with "=" and "?", but there's other code that splits the query string on "=", causing the prepared statement to be malformed. If I look at the comments on https://issues.apache.org/jira/browse/CASSANDRA-5867, where this change was made, I see a single mention of URL encoding the CQL query. Is this the expectation going forward? Was there a reason that the "#" and "@" mappings were removed? Further: I've tried URL encoding, and changing the CqlStorage code back to its previous behavior. I get the same error in this case of a long being a different size than expected. > Changes for Pig collections break CQL prepared statements > - > > Key: CASSANDRA-6073 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6073 > Project: Cassandra > Issue Type: Bug > Components: Hadoop > Environment: 1.2.10-tentative branch >Reporter: Chad Johnston > > I've checked out and built the 1.2.10-tentative branch, and I've noticed that > all of my CQL prepared statements are now broken. > Looking into the code, it looks like the "#" -> "=" and "@" -> "?" > translations were removed. I tried to replace these in one of my scripts with > "=" and "?", but there's other code that splits the query string on "=", > causing the prepared statement to be malformed. > If I look at the comments on > https://issues.apache.org/jira/browse/CASSANDRA-5867, where this change was > made, I see a single mention of URL encoding the CQL query. Is this the > expectation going forward? Was there a reason that the "#" and "@" mappings > were removed? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-6083) Pig requires explicit cast from int to long to save to Cassandra
Chad Johnston created CASSANDRA-6083: Summary: Pig requires explicit cast from int to long to save to Cassandra Key: CASSANDRA-6083 URL: https://issues.apache.org/jira/browse/CASSANDRA-6083 Project: Cassandra Issue Type: Bug Components: Hadoop Reporter: Chad Johnston Priority: Minor Since version 1.2.10, I have to manually cast any int values in Pig to long in order to store them into bigint Cassandra columns. I did not have to perform this cast in previous versions of Cassandra. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-6073) Changes for Pig collections break CQL prepared statements
Chad Johnston created CASSANDRA-6073: Summary: Changes for Pig collections break CQL prepared statements Key: CASSANDRA-6073 URL: https://issues.apache.org/jira/browse/CASSANDRA-6073 Project: Cassandra Issue Type: Bug Components: Hadoop Environment: 1.2.10-tentative branch Reporter: Chad Johnston I've checked out and built the 1.2.10-tentative branch, and I've noticed that all of my CQL prepared statements are now broken. Looking into the code, it looks like the "#" -> "=" and "@" -> "?" translations were removed. I tried to replace these in one of my scripts with "=" and "?", but there's other code that splits the query string on "=", causing the prepared statement to be malformed. If I look at the comments on https://issues.apache.org/jira/browse/CASSANDRA-5867, where this change was made, I see a single mention of URL encoding the CQL query. Is this the expectation going forward? Was there a reason that the "#" and "@" mappings were removed? Further: I've tried URL encoding, and changing the CqlStorage code back to its previous behavior. I get the same error in this case of a long being a different size than expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
