[jira] [Commented] (CASSANDRA-5816) [PATCH] Debian packaging: also recommend chrony and ptpd in addition to ntp
[
https://issues.apache.org/jira/browse/CASSANDRA-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722887#comment-13722887
]
paul cannon commented on CASSANDRA-5816:
bq. 2) This change makes it easier to deploy Cassandra than have to deal with a
one-off change to have apt ignore recommendations.
No one-off changes are necessary; if you explicitly tell apt to uninstall ntp
and install chrony, it will happily do so. Apt, by default, will install
Recommends: when you ask for a package, but it won't complain if you want
something else.
bq. 3) In 7 years of deploying Ubuntu systems I haven't needed to learn about
changing recommendations, so make the package work with the standards that
other packages do.
Using Recommends: this way is wholly compliant with Debian and Ubuntu policies.
If users were not ever expected to leave Recommends unsatisfied, it would be
the same thing as Depends.
[PATCH] Debian packaging: also recommend chrony and ptpd in addition to ntp
---
Key: CASSANDRA-5816
URL: https://issues.apache.org/jira/browse/CASSANDRA-5816
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Affects Versions: 1.2.7
Reporter: Blair Zajac
Assignee: Blair Zajac
Priority: Minor
I'm switching my Ubuntu servers running Cassandra from ntp to chrony for the
reasons cited here when Fedora made the switch to have chrony be the default
NTP client:
http://fedoraproject.org/wiki/Features/ChronyDefaultNTP
Currently, the debian packaging recommends only ntp so if chrony is installed
it'll want to remove it and install ntp. I also added ptpd, the Precision
Time Protocol daemon, which is another time syncing server for completeness.
Please apply this to the 1.2 branch so the next 1.2.x release can deploy with
chrony.
Below is the patch since it's a one-liner.
Thanks,
Blair
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ Standards-Version: 3.8.3
Package: cassandra
Architecture: all
Depends: openjdk-6-jre-headless (= 6b11) | java6-runtime, jsvc (= 1.0),
libcommons-daemon-java (= 1.0), adduser, libjna-java, python (= 2.5),
python-support (= 0.90.0), ${misc:Depends}
-Recommends: ntp
+Recommends: chrony | ntp | ptpd
Conflicts: apache-cassandra1
Replaces: apache-cassandra1
Description: distributed storage system for structured data
--
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-5816) [PATCH] Debian packaging: also recommend chrony and ptpd in addition to ntp
[
https://issues.apache.org/jira/browse/CASSANDRA-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722936#comment-13722936
]
paul cannon commented on CASSANDRA-5816:
You want
{noformat}
apt-get install cassandra chrony
{noformat}
or
{noformat}
apt-get install cassandra
apt-get install chrony
{noformat}
If you install chrony first, apt has no way to know that you'd prefer to keep
chrony over meeting the recommendation from the Cassandra package. If you have
an automated package-set-management system, it should know how to request
installation of multiple packages in one command like this, so that apt can
best sort out dependency trees and scoring based on what you have explicitly
requested. Alternatively, you could set appropriate pinning for chrony and/or
ntp in apt_preferences.
I'm not debating whether using {{ntp | time-daemon}} is the right thing to do
or not (I don't care), but I feel like a better understanding of the problem
would help everyone involved.
[PATCH] Debian packaging: also recommend chrony and ptpd in addition to ntp
---
Key: CASSANDRA-5816
URL: https://issues.apache.org/jira/browse/CASSANDRA-5816
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Affects Versions: 1.2.7
Reporter: Blair Zajac
Assignee: Blair Zajac
Priority: Minor
I'm switching my Ubuntu servers running Cassandra from ntp to chrony for the
reasons cited here when Fedora made the switch to have chrony be the default
NTP client:
http://fedoraproject.org/wiki/Features/ChronyDefaultNTP
Currently, the debian packaging recommends only ntp so if chrony is installed
it'll want to remove it and install ntp. I also added ptpd, the Precision
Time Protocol daemon, which is another time syncing server for completeness.
Please apply this to the 1.2 branch so the next 1.2.x release can deploy with
chrony.
Below is the patch since it's a one-liner.
Thanks,
Blair
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ Standards-Version: 3.8.3
Package: cassandra
Architecture: all
Depends: openjdk-6-jre-headless (= 6b11) | java6-runtime, jsvc (= 1.0),
libcommons-daemon-java (= 1.0), adduser, libjna-java, python (= 2.5),
python-support (= 0.90.0), ${misc:Depends}
-Recommends: ntp
+Recommends: chrony | ntp | ptpd
Conflicts: apache-cassandra1
Replaces: apache-cassandra1
Description: distributed storage system for structured data
--
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-5662) Wasted work in StorageService.initClient()
[ https://issues.apache.org/jira/browse/CASSANDRA-5662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-5662: --- Labels: label performance (was: performance) Wasted work in StorageService.initClient() -- Key: CASSANDRA-5662 URL: https://issues.apache.org/jira/browse/CASSANDRA-5662 Project: Cassandra Issue Type: Task Environment: any Reporter: Adrian Nistor Assignee: Adrian Nistor Priority: Trivial Labels: label, performance Fix For: 1.2.6 Attachments: patch.diff The problem appears in version 1.2.5 and in revision 26018be2.. I attached a one-line patch that fixes it. In method StorageService.initClient, the loop over Gossiper.instance.getLiveMembers() should break immediately after isUp is set to true. All the iterations after isUp is set to true do not perform any useful work, at best they just set isUp again to true. Method getCompactedRow in class ParallelCompactionIterable.Reducer has a similar loop (over rows), and this loop breaks immediately after inMemory is set to false, just like in the proposed patch. Other methods (e.g., GroupByPrefix.count, SecondaryIndex.buildIndexAsync) also have similar loops with similar breaks, just like in the proposed patch. -- 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-3799) cqlsh: ASSUME should also change how values are sent to cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-3799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13483374#comment-13483374 ] paul cannon commented on CASSANDRA-3799: Just to clarify for others, it might not be as bad as it sounds, since cqlsh already parses every insert, update, and batch, including contained statements. The difficulty is just in making sure that cqlsh can marshal textual values (from user input) and then unmarshal them again, both in the same way that Cassandra will do for the same contexts. cqlsh: ASSUME should also change how values are sent to cassandra - Key: CASSANDRA-3799 URL: https://issues.apache.org/jira/browse/CASSANDRA-3799 Project: Cassandra Issue Type: New Feature Components: Tools Affects Versions: 1.0.3 Reporter: paul cannon Assignee: Aleksey Yeschenko Priority: Minor Labels: cqlsh Fix For: 1.3 cqlsh's ASSUME command currently only changes how query *return* values are deserialized, and never transforms user CQL text before sending to Cassandra. Apparently cassandra-cli also changes how values are interpreted and marshaled for Cassandra, so user expectation is that cqlsh should also do this. -- 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-4717) cqlsh fails to format values of ReversedType-wrapped classes
[ https://issues.apache.org/jira/browse/CASSANDRA-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463940#comment-13463940 ] paul cannon commented on CASSANDRA-4717: Sorry, you're right, this patch was only for trunk. The 1.1 branch doesn't have formatting.py or displaying.py. The patch will be easy to adapt- I can do it within a day or two, if no one else picks it up cqlsh fails to format values of ReversedType-wrapped classes Key: CASSANDRA-4717 URL: https://issues.apache.org/jira/browse/CASSANDRA-4717 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1.0 Reporter: paul cannon Assignee: paul cannon Priority: Minor Labels: cqlsh Fix For: 1.1.6 Attachments: 4717.patch.txt, 4717-test.patch.txt See the test case for CASSANDRA-4715, but run it on trunk. The ReversedType-wrapped column (rdate) will be displayed as a floating-point integer (it gets deserialized into a native type correctly, but cqlsh's format-according-to-type machinery doesn't know how to handle the cqltypes.ReversedType subclass. -- 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-4488) update cqlsh recognized syntax (for tab completion, etc)
[
https://issues.apache.org/jira/browse/CASSANDRA-4488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13464090#comment-13464090
]
paul cannon commented on CASSANDRA-4488:
The machinery needs to be able to parse an entire line up to the completion
point, or it has no way of knowing what the context is. Since many people have
reported cqlsh's context-sensitive completion of things like columnfamily
properties and possible values as useful, cqlsh needs to be able to recognize
that map literals are valid property values, etc. Cqlsh also needs to know that
composite row keys are possible or it wouldn't be able to figure out when a
CREATE TABLE statement's column definitions were done and when the options are
supposed to come.
From a different direction, cqlsh is supposed to be able to DESCRIBE keyspaces
and tables using current, valid syntax. People complain and write bug reports
when they copy and paste DESCRIBE output and they get an error. So, the
DESCRIBE machinery also needs to know how to show options in the map format
and when to use the old syntax instead.
I have a pretty huge patch toward this end already, which not only allows
parsing the new syntax, but also recognizes when it should be used versus the
old syntax (3.0.0-beta1 for cassandra-1.1 servers), updates cqlsh's idea of
what properties are valid and how they look ('compaction' as a map for 1.2 vs
'compaction_strategy_options' as a prefix for 1.1, etc), updates DESCRIBE
KEYSPACE and DESCRIBE TABLE, adds hints to INSERT and UPDATE statements to let
the user know what type is expected in a particular value position, and starts
using schema_columnfamilies to get the list of available column names in
certain cases since thrift doesn't report all of them anymore.
The only thing I have left to add there is the GRANT and REVOKE statements from
CASSANDRA-4490, which should be pretty straightforward. I can attach what I
have so far if you'd rather have Aleksey finish it off.
update cqlsh recognized syntax (for tab completion, etc)
Key: CASSANDRA-4488
URL: https://issues.apache.org/jira/browse/CASSANDRA-4488
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: paul cannon
Assignee: Aleksey Yeschenko
Priority: Minor
Fix For: 1.1.6
cqlsh syntax awareness (tab completion, etc) should be aware of several
recent changes to CQL:
* CASSANDRA-4179 (row key and column value composites; 1.2 only)
* CASSANDRA-3647 (sets/lists/maps; 1.2 only)
* CASSANDRA-4018 (inet type; 1.2 only)
* CASSANDRA-4278 (hyphens in keyspace properties; 1.1 and up)
* CASSANDRA-4217 (accessing ttl, timestamp; 1.1 and up)
--
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-4416) Include metadata for system keyspace itself in schema_* tables
[
https://issues.apache.org/jira/browse/CASSANDRA-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13464419#comment-13464419
]
paul cannon commented on CASSANDRA-4416:
This is more important now, after CASSANDRA-4377, since as far as I can tell
there is no way at all for a client or user to be able to see all the tables in
the system and system_traces keyspaces.
Include metadata for system keyspace itself in schema_* tables
--
Key: CASSANDRA-4416
URL: https://issues.apache.org/jira/browse/CASSANDRA-4416
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.2.0 beta 1
Reporter: paul cannon
Priority: Minor
Labels: cql, cql3
The `system.schema_keyspaces`, `system.schema_columnfamilies`, and
`system.schema_columns` virtual tables allow clients to query schema and
layout information through CQL. This will be invaluable when users start to
make more use of the CQL-only protocol (CASSANDRA-2478), since there will be
no other way to determine certain information about available columnfamilies,
keyspaces, or show metadata about them.
However, the system keyspace itself, and all the columnfamilies in it, are
not represented in the schema_* tables:
{noformat}
cqlsh select * from system.schema_keyspaces where keyspace = 'system';
cqlsh
cqlsh select * from system.schema_columnfamilies where keyspace = 'system';
cqlsh
cqlsh select * from system.schema_columns where keyspace = 'system';
cqlsh
{noformat}
It would be greatly helpful to clients which do more introspection than the
minimum (say, for example, cqlsh) to be able to get information on the
structure and availability of schema-definition tables.
--
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-4488) update cqlsh recognized syntax (for tab completion, etc)
[ https://issues.apache.org/jira/browse/CASSANDRA-4488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-4488: --- Attachment: 4488.patch.txt There we go. The patch really applies on top of the patch from CASSANDRA-3920, since it adds to the tests, but if you want to commit this first you can just snip out the tests part until later. update cqlsh recognized syntax (for tab completion, etc) Key: CASSANDRA-4488 URL: https://issues.apache.org/jira/browse/CASSANDRA-4488 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: paul cannon Assignee: paul cannon Priority: Minor Fix For: 1.1.6 Attachments: 4488.patch.txt cqlsh syntax awareness (tab completion, etc) should be aware of several recent changes to CQL: * CASSANDRA-4179 (row key and column value composites; 1.2 only) * CASSANDRA-3647 (sets/lists/maps; 1.2 only) * CASSANDRA-4018 (inet type; 1.2 only) * CASSANDRA-4278 (hyphens in keyspace properties; 1.1 and up) * CASSANDRA-4217 (accessing ttl, timestamp; 1.1 and up) -- 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-4334) cqlsh tab completion error in CREATE KEYSPACE
[
https://issues.apache.org/jira/browse/CASSANDRA-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462478#comment-13462478
]
paul cannon commented on CASSANDRA-4334:
Aleksey: nice, this was the same solution I came up with tonight before
realizing you'd already solved it. You'll also want to check, though, that
{{lasttype != 'unclosedName'}} - the same bug will manifest for double-quoted
names in cql3 mode otherwise.
cqlsh tab completion error in CREATE KEYSPACE
---
Key: CASSANDRA-4334
URL: https://issues.apache.org/jira/browse/CASSANDRA-4334
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.0
Environment: ubuntu, git:cassandra-1.1. I see the error in cqlsh with
cql2 and cql3.
Reporter: Tyler Patterson
Assignee: Aleksey Yeschenko
Priority: Minor
Fix For: 1.1.6
Attachments: 4334-1.1-patch.txt, 4334-1.2-patch.txt
The following:
{code}
cqlsh CREATE KEYSPACE test WITH strategy_class = 'STAB
{code}
will tab complete like this:
{code}
cqlsh CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy '
{code}
Note the extra space after SimpleStrategy. Not a big deal to remove, but it
could be misleading to people.
--
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-4715) cqlsh doesn't properly decode reversed timestamps
[
https://issues.apache.org/jira/browse/CASSANDRA-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462942#comment-13462942
]
paul cannon commented on CASSANDRA-4715:
The CQL library didn't learn how to deal with parameterized validation classes
like ReversedType until the fairly heavy changes for the 1.1.0 version, and
Cassandra 1.1 only has python-cql 1.0.10 bundled with it. I'm not sure how
simple it would be to swap in 1.1; probably simple, but maybe not.
I had intended just not to support displaying ReversedType values and so on
until cassandra 1.2's cqlsh, but maybe someone can pick it up.
cqlsh doesn't properly decode reversed timestamps
-
Key: CASSANDRA-4715
URL: https://issues.apache.org/jira/browse/CASSANDRA-4715
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Reporter: T Jake Luciani
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Example:
{code}
cqlsh:test
cqlsh:test CREATE TABLE testrev (
... key text,
... rdate timestamp,
... num double,
... PRIMARY KEY(key,rdate)
... ) WITH COMPACT STORAGE
... AND CLUSTERING ORDER BY(rdate DESC);
cqlsh:test INSERT INTO testrev(key,rdate,num) VALUES
('foo','2012-01-01',10.5);
cqlsh:test select * from test
test.testrev
cqlsh:test select * from testrev ;
key | rdate| num
-+--+--
foo | ☺4-£x? | 10.5
Failed to decode value '\x00\x00\x014\x97\xa3x\x80' (for column 'rdate') as
'org.apache.cassandra.db.marshal.ReversedType': global name 'self' is
not defined
cqlsh:test
{code}
--
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] [Comment Edited] (CASSANDRA-4715) cqlsh doesn't properly decode reversed timestamps
[
https://issues.apache.org/jira/browse/CASSANDRA-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462942#comment-13462942
]
paul cannon edited comment on CASSANDRA-4715 at 9/26/12 3:44 AM:
-
The CQL library didn't learn how to deal with parameterized validation classes
like ReversedType until the fairly heavy changes for the python-cql 1.1.0
version, and Cassandra 1.1 only has python-cql 1.0.10 bundled with it. I'm not
sure how simple it would be to swap in python-cql 1.1; probably simple, but
maybe not.
I had intended just not to support displaying ReversedType values and so on
until cassandra 1.2's cqlsh, but maybe someone can pick it up.
was (Author: thepaul):
The CQL library didn't learn how to deal with parameterized validation
classes like ReversedType until the fairly heavy changes for the 1.1.0 version,
and Cassandra 1.1 only has python-cql 1.0.10 bundled with it. I'm not sure how
simple it would be to swap in 1.1; probably simple, but maybe not.
I had intended just not to support displaying ReversedType values and so on
until cassandra 1.2's cqlsh, but maybe someone can pick it up.
cqlsh doesn't properly decode reversed timestamps
-
Key: CASSANDRA-4715
URL: https://issues.apache.org/jira/browse/CASSANDRA-4715
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Reporter: T Jake Luciani
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Example:
{code}
cqlsh:test
cqlsh:test CREATE TABLE testrev (
... key text,
... rdate timestamp,
... num double,
... PRIMARY KEY(key,rdate)
... ) WITH COMPACT STORAGE
... AND CLUSTERING ORDER BY(rdate DESC);
cqlsh:test INSERT INTO testrev(key,rdate,num) VALUES
('foo','2012-01-01',10.5);
cqlsh:test select * from test
test.testrev
cqlsh:test select * from testrev ;
key | rdate| num
-+--+--
foo | ☺4-£x? | 10.5
Failed to decode value '\x00\x00\x014\x97\xa3x\x80' (for column 'rdate') as
'org.apache.cassandra.db.marshal.ReversedType': global name 'self' is
not defined
cqlsh:test
{code}
--
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-4717) cqlsh fails to format values of ReversedType-wrapped classes
paul cannon created CASSANDRA-4717: -- Summary: cqlsh fails to format values of ReversedType-wrapped classes Key: CASSANDRA-4717 URL: https://issues.apache.org/jira/browse/CASSANDRA-4717 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1.0 Reporter: paul cannon Assignee: Aleksey Yeschenko Priority: Minor Fix For: 1.1.6 See the test case for CASSANDRA-4715, but run it on trunk. The ReversedType-wrapped column (rdate) will be displayed as a floating-point integer (it gets deserialized into a native type correctly, but cqlsh's format-according-to-type machinery doesn't know how to handle the cqltypes.ReversedType subclass. -- 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-4717) cqlsh fails to format values of ReversedType-wrapped classes
[ https://issues.apache.org/jira/browse/CASSANDRA-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-4717: --- Attachment: 4717-test.patch.txt 4717.patch.txt 4717.patch.txt is a fix; 4717-test.patch.txt adds a test for it that fits in the framework from CASSANDRA-3920, if you guys decide to add that. cqlsh fails to format values of ReversedType-wrapped classes Key: CASSANDRA-4717 URL: https://issues.apache.org/jira/browse/CASSANDRA-4717 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1.0 Reporter: paul cannon Assignee: Aleksey Yeschenko Priority: Minor Labels: cqlsh Fix For: 1.1.6 Attachments: 4717.patch.txt, 4717-test.patch.txt See the test case for CASSANDRA-4715, but run it on trunk. The ReversedType-wrapped column (rdate) will be displayed as a floating-point integer (it gets deserialized into a native type correctly, but cqlsh's format-according-to-type machinery doesn't know how to handle the cqltypes.ReversedType subclass. -- 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-4717) cqlsh fails to format values of ReversedType-wrapped classes
[ https://issues.apache.org/jira/browse/CASSANDRA-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462997#comment-13462997 ] paul cannon commented on CASSANDRA-4717: I'm not sure whether it's better for the thrift interface to include ReversedType in the resultset or not, but the cql library can handle it either way. And this fix for cqlsh is pretty simple too. If you do want to change the interface so that ReversedType doesn't get reported, then 4715 probably is a dupe. Otherwise, it's a different problem with a different solution. This isn't specific to cql2. cqlsh fails to format values of ReversedType-wrapped classes Key: CASSANDRA-4717 URL: https://issues.apache.org/jira/browse/CASSANDRA-4717 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1.0 Reporter: paul cannon Assignee: Aleksey Yeschenko Priority: Minor Labels: cqlsh Fix For: 1.1.6 Attachments: 4717.patch.txt, 4717-test.patch.txt See the test case for CASSANDRA-4715, but run it on trunk. The ReversedType-wrapped column (rdate) will be displayed as a floating-point integer (it gets deserialized into a native type correctly, but cqlsh's format-according-to-type machinery doesn't know how to handle the cqltypes.ReversedType subclass. -- 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-4715) cqlsh doesn't properly decode reversed timestamps
[
https://issues.apache.org/jira/browse/CASSANDRA-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462999#comment-13462999
]
paul cannon commented on CASSANDRA-4715:
No. Jake's example case above is cql3-only, but this problem likely shows up in
either mode.
cqlsh doesn't properly decode reversed timestamps
-
Key: CASSANDRA-4715
URL: https://issues.apache.org/jira/browse/CASSANDRA-4715
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Reporter: T Jake Luciani
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Example:
{code}
cqlsh:test
cqlsh:test CREATE TABLE testrev (
... key text,
... rdate timestamp,
... num double,
... PRIMARY KEY(key,rdate)
... ) WITH COMPACT STORAGE
... AND CLUSTERING ORDER BY(rdate DESC);
cqlsh:test INSERT INTO testrev(key,rdate,num) VALUES
('foo','2012-01-01',10.5);
cqlsh:test select * from test
test.testrev
cqlsh:test select * from testrev ;
key | rdate| num
-+--+--
foo | ☺4-£x? | 10.5
Failed to decode value '\x00\x00\x014\x97\xa3x\x80' (for column 'rdate') as
'org.apache.cassandra.db.marshal.ReversedType': global name 'self' is
not defined
cqlsh:test
{code}
--
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-4719) binary protocol: when an invalid event type is watched via a REGISTER message, the response message does not have an associated stream id
paul cannon created CASSANDRA-4719: -- Summary: binary protocol: when an invalid event type is watched via a REGISTER message, the response message does not have an associated stream id Key: CASSANDRA-4719 URL: https://issues.apache.org/jira/browse/CASSANDRA-4719 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.2.0 beta 1 Reporter: paul cannon Priority: Minor Fix For: 1.2.0 I tried sending a REGISTER message with an eventlist including the string STATUS_FOO, in order to test error handling in the python driver for that eventuality. But the response from the server (a Server error with a message of java.lang.IllegalArgumentException: No enum const class org.apache.cassandra.transport.Event$Type.STATUS_FOO) had a stream_id of 0, so the driver was not able to associate it with the request. -- 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-4720) cqlsh fails to format timeuuid values
[
https://issues.apache.org/jira/browse/CASSANDRA-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon updated CASSANDRA-4720:
---
Attachment: 4720.patch.txt
fixes the problem.
cqlsh fails to format timeuuid values
-
Key: CASSANDRA-4720
URL: https://issues.apache.org/jira/browse/CASSANDRA-4720
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.2.0 beta 1
Reporter: paul cannon
Fix For: 1.2.0
Attachments: 4720.patch.txt
If a user has a table with a timeuuid column, and the user tries to select
some rows containing timeuuid values, a weird error results:
{noformat}
global name 'unix_time_from_uuid1' is not defined
{noformat}
Not very helpful. It should probably display the timeuuid somehow.
--
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-4720) cqlsh fails to format timeuuid values
paul cannon created CASSANDRA-4720:
--
Summary: cqlsh fails to format timeuuid values
Key: CASSANDRA-4720
URL: https://issues.apache.org/jira/browse/CASSANDRA-4720
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.2.0 beta 1
Reporter: paul cannon
Fix For: 1.2.0
Attachments: 4720.patch.txt
If a user has a table with a timeuuid column, and the user tries to select some
rows containing timeuuid values, a weird error results:
{noformat}
global name 'unix_time_from_uuid1' is not defined
{noformat}
Not very helpful. It should probably display the timeuuid somehow.
--
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-4720) cqlsh fails to format timeuuid values
[
https://issues.apache.org/jira/browse/CASSANDRA-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463359#comment-13463359
]
paul cannon commented on CASSANDRA-4720:
sorry Aleksey, my fault, I guessed you were the one to automatically get new
cqlsh tickets. But then I went and fixed it myself anyway, because my memory
sucks. :)
cqlsh fails to format timeuuid values
-
Key: CASSANDRA-4720
URL: https://issues.apache.org/jira/browse/CASSANDRA-4720
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.2.0 beta 1
Reporter: paul cannon
Assignee: paul cannon
Labels: cqlsh
Fix For: 1.2.0 beta 2
Attachments: 4720.patch.txt
If a user has a table with a timeuuid column, and the user tries to select
some rows containing timeuuid values, a weird error results:
{noformat}
global name 'unix_time_from_uuid1' is not defined
{noformat}
Not very helpful. It should probably display the timeuuid somehow.
--
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-3920) tests for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-3920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13460251#comment-13460251 ] paul cannon commented on CASSANDRA-3920: Here's what I had so far. It's a pretty good start and has enough framework for easily testing some fairly complicated things like tab-completion, output formatting, and value coloring. The suite requires nosetests. https://github.com/thepaul/cassandra/commit/a5aedeb40 let me know if I can explain any of it. tests for cqlsh --- Key: CASSANDRA-3920 URL: https://issues.apache.org/jira/browse/CASSANDRA-3920 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: paul cannon Assignee: Aleksey Yeschenko Priority: Minor Labels: cqlsh Cqlsh has become big enough and tries to cover enough situations that it's time to start acting like a responsible adult and make this bugger some unit tests to guard against regressions. -- 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-4649) Cassandra 1.2 should not accept CQL version 3.0.0-beta1
[ https://issues.apache.org/jira/browse/CASSANDRA-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459723#comment-13459723 ] paul cannon commented on CASSANDRA-4649: +1. Cassandra 1.2 should not accept CQL version 3.0.0-beta1 - Key: CASSANDRA-4649 URL: https://issues.apache.org/jira/browse/CASSANDRA-4649 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.2.0 Reporter: paul cannon Assignee: Sylvain Lebresne Priority: Minor Labels: cql3 Attachments: 4649.txt During Cassandra 1.1's whole lifecycle, the CREATE KEYSPACE syntax was pretty dramatically and incompatibly different from what is there now for 1.2. That's ok, since we explicitly said there could be breaking changes in the syntax before 3.0.0 final, but at least we should make it clear that 3.0.0 is not compatible with the 3.0.0-beta1 syntax we had out for quite a while. If we don't want to reject connections asking for 3.0.0-beta1, we should bump the version number to 3.0.1 or something. -- 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-4649) Cassandra 1.2 should not accept CQL version 3.0.0-beta1
[ https://issues.apache.org/jira/browse/CASSANDRA-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-4649: --- Reviewer: thepaul Cassandra 1.2 should not accept CQL version 3.0.0-beta1 - Key: CASSANDRA-4649 URL: https://issues.apache.org/jira/browse/CASSANDRA-4649 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.2.0 Reporter: paul cannon Assignee: Sylvain Lebresne Priority: Minor Labels: cql3 Attachments: 4649.txt During Cassandra 1.1's whole lifecycle, the CREATE KEYSPACE syntax was pretty dramatically and incompatibly different from what is there now for 1.2. That's ok, since we explicitly said there could be breaking changes in the syntax before 3.0.0 final, but at least we should make it clear that 3.0.0 is not compatible with the 3.0.0-beta1 syntax we had out for quite a while. If we don't want to reject connections asking for 3.0.0-beta1, we should bump the version number to 3.0.1 or something. -- 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-4594) COPY TO and COPY FROM don't default to consistent ordering of columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457999#comment-13457999
]
paul cannon commented on CASSANDRA-4594:
Aleksey: you must be missing the patch for this ticket. It includes a change to
the cql_protect_name function to encode unicode names in utf8 when necessary.
Using {{str}} won't work when there are non-ascii characters and the default
encoding is not utf8.
COPY TO and COPY FROM don't default to consistent ordering of columns
-
Key: CASSANDRA-4594
URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
Project: Cassandra
Issue Type: Bug
Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Attachments: lazy-fix.txt
Here is the input:
{code}
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
USE test;
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
COPY airplanes TO 'temp.cfg' WITH HEADER=true;
TRUNCATE airplanes;
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
SELECT * FROM airplanes;
{code}
Here is what happens when executed. Note how it tried to import the float
into the int column:
{code}
cqlsh:test DROP KEYSPACE test;
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
cqlsh:test USE test;
cqlsh:test
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,
... manufacturer ascii,
... year int,
... mach float
... );
cqlsh:test
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
1 rows exported in 0.003 seconds.
cqlsh:test TRUNCATE airplanes;
cqlsh:test
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'
Aborting import at record #0 (line 1). Previously-inserted values still
present.
0 rows imported in 0.002 seconds.
{code}
--
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-4594) COPY TO and COPY FROM don't default to consistent ordering of columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458022#comment-13458022
]
paul cannon commented on CASSANDRA-4594:
It's not yet in trunk. See above; Brandon couldn't get the commit to apply,
because it was missing two of the commits from 4491.
COPY TO and COPY FROM don't default to consistent ordering of columns
-
Key: CASSANDRA-4594
URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
Project: Cassandra
Issue Type: Bug
Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Attachments: lazy-fix.txt
Here is the input:
{code}
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
USE test;
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
COPY airplanes TO 'temp.cfg' WITH HEADER=true;
TRUNCATE airplanes;
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
SELECT * FROM airplanes;
{code}
Here is what happens when executed. Note how it tried to import the float
into the int column:
{code}
cqlsh:test DROP KEYSPACE test;
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
cqlsh:test USE test;
cqlsh:test
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,
... manufacturer ascii,
... year int,
... mach float
... );
cqlsh:test
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
1 rows exported in 0.003 seconds.
cqlsh:test TRUNCATE airplanes;
cqlsh:test
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'
Aborting import at record #0 (line 1). Previously-inserted values still
present.
0 rows imported in 0.002 seconds.
{code}
--
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-4594) COPY TO and COPY FROM don't default to consistent ordering of columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458039#comment-13458039
]
paul cannon commented on CASSANDRA-4594:
Yes, the commits from 4491 are there. The patch for _this commit_ is not.
COPY TO and COPY FROM don't default to consistent ordering of columns
-
Key: CASSANDRA-4594
URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
Project: Cassandra
Issue Type: Bug
Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Here is the input:
{code}
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
USE test;
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
COPY airplanes TO 'temp.cfg' WITH HEADER=true;
TRUNCATE airplanes;
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
SELECT * FROM airplanes;
{code}
Here is what happens when executed. Note how it tried to import the float
into the int column:
{code}
cqlsh:test DROP KEYSPACE test;
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
cqlsh:test USE test;
cqlsh:test
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,
... manufacturer ascii,
... year int,
... mach float
... );
cqlsh:test
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
1 rows exported in 0.003 seconds.
cqlsh:test TRUNCATE airplanes;
cqlsh:test
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'
Aborting import at record #0 (line 1). Previously-inserted values still
present.
0 rows imported in 0.002 seconds.
{code}
--
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-4594) COPY TO and COPY FROM don't default to consistent ordering of columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457594#comment-13457594
]
paul cannon commented on CASSANDRA-4594:
Ah, sorry, I didn't make it clear on 4491 that the github branch had multiple
commits from off of trunk. Looks like you only cherry-picked the last. I'll
make a note there.
COPY TO and COPY FROM don't default to consistent ordering of columns
-
Key: CASSANDRA-4594
URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
Project: Cassandra
Issue Type: Bug
Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Here is the input:
{code}
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
USE test;
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
COPY airplanes TO 'temp.cfg' WITH HEADER=true;
TRUNCATE airplanes;
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
SELECT * FROM airplanes;
{code}
Here is what happens when executed. Note how it tried to import the float
into the int column:
{code}
cqlsh:test DROP KEYSPACE test;
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
cqlsh:test USE test;
cqlsh:test
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,
... manufacturer ascii,
... year int,
... mach float
... );
cqlsh:test
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
1 rows exported in 0.003 seconds.
cqlsh:test TRUNCATE airplanes;
cqlsh:test
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'
Aborting import at record #0 (line 1). Previously-inserted values still
present.
0 rows imported in 0.002 seconds.
{code}
--
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] [Reopened] (CASSANDRA-4491) cqlsh needs to use system.local instead of system.Versions
[ https://issues.apache.org/jira/browse/CASSANDRA-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon reopened CASSANDRA-4491: Sorry, my fault for not being clear: this change involved multiple commits. Three, in this case. The last one got in right. cqlsh needs to use system.local instead of system.Versions -- Key: CASSANDRA-4491 URL: https://issues.apache.org/jira/browse/CASSANDRA-4491 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.2.0 beta 1 Reporter: paul cannon Assignee: paul cannon Priority: Minor Labels: cqlsh Fix For: 1.2.0 beta 1 Apparently the system.Versions table was removed as part of CASSANDRA-4018. cqlsh in 1.2 should use system.local preferentially, and fall back on system.Versions to keep backwards compatibility with older c*. Also changed in 4018: all the system.schema_* CFs now use columns named keyspace_name, columnfamily_name, and column_name instead of keyspace, columnfamily, and column. While we're at it, let's update the cql3 table structure parsing and the DESCRIBE command for the recent Cassandra changes too. -- 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-4491) cqlsh needs to use system.local instead of system.Versions
[ https://issues.apache.org/jira/browse/CASSANDRA-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-4491: --- Description: Apparently the system.Versions table was removed as part of CASSANDRA-4018. cqlsh in 1.2 should use system.local preferentially, and fall back on system.Versions to keep backwards compatibility with older c*. Also changed in 4018: all the system.schema_* CFs now use columns named keyspace_name, columnfamily_name, and column_name instead of keyspace, columnfamily, and column. While we're at it, let's update the cql3 table structure parsing and the DESCRIBE command for the recent Cassandra changes too. was: Apparently the system.Versions table was removed as part of CASSANDRA-4018. cqlsh in 1.2 should use system.local preferentially, and fall back on system.Versions to keep backwards compatibility with older c*. Also changed in 4018: all the system.schema_* CFs now use columns named keyspace_name, columnfamily_name, and column_name instead of keyspace, columnfamily, and column. cqlsh needs to use system.local instead of system.Versions -- Key: CASSANDRA-4491 URL: https://issues.apache.org/jira/browse/CASSANDRA-4491 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.2.0 beta 1 Reporter: paul cannon Assignee: paul cannon Priority: Minor Labels: cqlsh Fix For: 1.2.0 Apparently the system.Versions table was removed as part of CASSANDRA-4018. cqlsh in 1.2 should use system.local preferentially, and fall back on system.Versions to keep backwards compatibility with older c*. Also changed in 4018: all the system.schema_* CFs now use columns named keyspace_name, columnfamily_name, and column_name instead of keyspace, columnfamily, and column. While we're at it, let's update the cql3 table structure parsing and the DESCRIBE command for the recent Cassandra changes too. -- 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-4627) support inet data type
[ https://issues.apache.org/jira/browse/CASSANDRA-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-4627: --- Reviewer: brandon.williams My additional changes committed into the 4627 branch in my github clone: http://github.com/thepaul/cassandra/tree/4627 Notice that this includes an update of the internal CQL lib, so there's a zipfile to add and one to remove. support inet data type -- Key: CASSANDRA-4627 URL: https://issues.apache.org/jira/browse/CASSANDRA-4627 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.2.0 beta 1 Reporter: paul cannon Assignee: paul cannon Labels: cql, cqlsh Fix For: 1.2.0 beta 1 Attachments: 4627.txt CASSANDRA-4018 introduced a new cassandra data type with a cql name inet, which is not yet supported in cqlsh. Add support for decoding and formatting. -- 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-4500) cqlsh: understand updated encodings for collections
[ https://issues.apache.org/jira/browse/CASSANDRA-4500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453394#comment-13453394 ] paul cannon commented on CASSANDRA-4500: Yeah, it was on purpose. I'd have used an immutable dict for the maps as well, if it were readily available. I don't think there should be any expectations that the thing called a list in CQL parlance is the same thing as a list in Python. cqlsh: understand updated encodings for collections --- Key: CASSANDRA-4500 URL: https://issues.apache.org/jira/browse/CASSANDRA-4500 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.2.0 beta 1 Reporter: paul cannon Assignee: paul cannon Labels: cqlsh Fix For: 1.2.0 beta 1 Attachments: 4500.patch.txt After CASSANDRA-4453, collections will be represented using the binary encoding in thrift CqlResults instead of json. Update cqlsh (and python-cql as necessary) to support. -- 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-4649) Cassandra 1.2 should not accept CQL version 3.0.0-beta1
paul cannon created CASSANDRA-4649: -- Summary: Cassandra 1.2 should not accept CQL version 3.0.0-beta1 Key: CASSANDRA-4649 URL: https://issues.apache.org/jira/browse/CASSANDRA-4649 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.2.0 Reporter: paul cannon Priority: Minor -- 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-4649) Cassandra 1.2 should not accept CQL version 3.0.0-beta1
[ https://issues.apache.org/jira/browse/CASSANDRA-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-4649: --- Description: During Cassandra 1.1's whole lifecycle, the CREATE KEYSPACE syntax was pretty dramatically and incompatibly different from what is there now for 1.2. That's ok, since we explicitly said there could be breaking changes in the syntax before 3.0.0 final, but at least we should make it clear that 3.0.0 is not compatible with the 3.0.0-beta1 syntax we had out for quite a while. If we don't want to reject connections asking for 3.0.0-beta1, we should bump the version number to 3.0.1 or something. Labels: cql3 (was: ) Cassandra 1.2 should not accept CQL version 3.0.0-beta1 - Key: CASSANDRA-4649 URL: https://issues.apache.org/jira/browse/CASSANDRA-4649 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.2.0 Reporter: paul cannon Priority: Minor Labels: cql3 During Cassandra 1.1's whole lifecycle, the CREATE KEYSPACE syntax was pretty dramatically and incompatibly different from what is there now for 1.2. That's ok, since we explicitly said there could be breaking changes in the syntax before 3.0.0 final, but at least we should make it clear that 3.0.0 is not compatible with the 3.0.0-beta1 syntax we had out for quite a while. If we don't want to reject connections asking for 3.0.0-beta1, we should bump the version number to 3.0.1 or something. -- 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-4627) support inet data type
[ https://issues.apache.org/jira/browse/CASSANDRA-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13452101#comment-13452101 ] paul cannon commented on CASSANDRA-4627: Oops, I intended this to be just for adding the support to cqlsh. But your patch does add useful support, so I'm in favor of including that as well. I just ask that we not commit it or close the ticket until I can add in the driver update. support inet data type -- Key: CASSANDRA-4627 URL: https://issues.apache.org/jira/browse/CASSANDRA-4627 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.2.0 beta 1 Reporter: paul cannon Assignee: paul cannon Labels: cql, cqlsh Fix For: 1.2.0 beta 1 Attachments: 4627.txt CASSANDRA-4018 introduced a new cassandra data type with a cql name inet, which is not yet supported in cqlsh. Add support for decoding and formatting. -- 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-4380) CQLSH: describe command doesn't output valid CQL command.
[
https://issues.apache.org/jira/browse/CASSANDRA-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13452102#comment-13452102
]
paul cannon commented on CASSANDRA-4380:
Marcos- there isn't any way to recreate some CQL 2 tables in CQL 3. CQL 3 can
model the same data, but the structure of the table needs to be different.
Cqlsh does the best that it can here, but if you want a better guarantee of
valid reconstruction of CQL 2 tables, use cqlsh in CQL 2 mode.
CQLSH: describe command doesn't output valid CQL command.
-
Key: CASSANDRA-4380
URL: https://issues.apache.org/jira/browse/CASSANDRA-4380
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Nick Bailey
Assignee: paul cannon
Labels: cqlsh
Fix For: 1.1.3
{noformat}
cqlsh:test describe columnfamily stats;
CREATE TABLE stats (
gid blob PRIMARY KEY
) WITH
comment='' AND
comparator='CompositeType(org.apache.cassandra.db.marshal.Int32Type,org.apache.cassandra.db.marshal.BytesType,org.apache.cassandra.db.marshal.UTF8Type)'
AND
read_repair_chance=0.10 AND
gc_grace_seconds=864000 AND
default_validation=blob AND
min_compaction_threshold=4 AND
max_compaction_threshold=32 AND
replicate_on_write='true' AND
compaction_strategy_class='SizeTieredCompactionStrategy' AND
compression_parameters:sstable_compression='SnappyCompressor';
{noformat}
I can create a cf in cql3 and then use describe cf to get the above output.
However trying to run that create statement says that all of the following
are invalid options:
* default_validation
* min_compaction_threshold
* max_compaction_threshold
* comparator
--
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] [Assigned] (CASSANDRA-4610) Add thrift transport factory impl to cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon reassigned CASSANDRA-4610: -- Assignee: paul cannon Add thrift transport factory impl to cqlsh -- Key: CASSANDRA-4610 URL: https://issues.apache.org/jira/browse/CASSANDRA-4610 Project: Cassandra Issue Type: Sub-task Reporter: T Jake Luciani Assignee: paul cannon -- 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-4380) CQLSH: describe command doesn't output valid CQL command.
[
https://issues.apache.org/jira/browse/CASSANDRA-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13452131#comment-13452131
]
paul cannon commented on CASSANDRA-4380:
bq. Doesn't COMPACT STORAGE provide the ability to model thrift/cql2-style
tables?
It does for some. It probably would in this case. It doesn't for the cases
where there are multiple columns with metadata in addition to
undefined/wide-row columns.
Maybe that's not a case worth worrying about, though. We could open a new
ticket for recreating thrift/cql2-style tables in CQL 3 mode with COMPACT
STORAGE and some made-up default column names like colname and value or
something.
CQLSH: describe command doesn't output valid CQL command.
-
Key: CASSANDRA-4380
URL: https://issues.apache.org/jira/browse/CASSANDRA-4380
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Nick Bailey
Assignee: paul cannon
Labels: cqlsh
Fix For: 1.1.3
{noformat}
cqlsh:test describe columnfamily stats;
CREATE TABLE stats (
gid blob PRIMARY KEY
) WITH
comment='' AND
comparator='CompositeType(org.apache.cassandra.db.marshal.Int32Type,org.apache.cassandra.db.marshal.BytesType,org.apache.cassandra.db.marshal.UTF8Type)'
AND
read_repair_chance=0.10 AND
gc_grace_seconds=864000 AND
default_validation=blob AND
min_compaction_threshold=4 AND
max_compaction_threshold=32 AND
replicate_on_write='true' AND
compaction_strategy_class='SizeTieredCompactionStrategy' AND
compression_parameters:sstable_compression='SnappyCompressor';
{noformat}
I can create a cf in cql3 and then use describe cf to get the above output.
However trying to run that create statement says that all of the following
are invalid options:
* default_validation
* min_compaction_threshold
* max_compaction_threshold
* comparator
--
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-4380) CQLSH: describe command doesn't output valid CQL command.
[
https://issues.apache.org/jira/browse/CASSANDRA-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13452284#comment-13452284
]
paul cannon commented on CASSANDRA-4380:
bq. for 1.2, provided you use the system.schema_columnfamilies table, it should
(almost) always be possible to create a valid CQL3 definition from an existing
CF
Could you elaborate on how that should be done? Say I made the following in
CQL2:
{noformat}
CREATE TABLE foo (t text PRIMARY KEY, f float, x uuid) WITH
default_validation=timestamp;
{noformat}
If that can be recreated in CQL 3, then I've missed a development somewhere.
bq. The Cassandra already does that (so that you can always access thrift CF
from CQL3), see CFDefinition.java. It could be worth using the same made-up
names here.
That's good to know. We should probably make that new ticket then.
CQLSH: describe command doesn't output valid CQL command.
-
Key: CASSANDRA-4380
URL: https://issues.apache.org/jira/browse/CASSANDRA-4380
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Nick Bailey
Assignee: paul cannon
Labels: cqlsh
Fix For: 1.1.3
{noformat}
cqlsh:test describe columnfamily stats;
CREATE TABLE stats (
gid blob PRIMARY KEY
) WITH
comment='' AND
comparator='CompositeType(org.apache.cassandra.db.marshal.Int32Type,org.apache.cassandra.db.marshal.BytesType,org.apache.cassandra.db.marshal.UTF8Type)'
AND
read_repair_chance=0.10 AND
gc_grace_seconds=864000 AND
default_validation=blob AND
min_compaction_threshold=4 AND
max_compaction_threshold=32 AND
replicate_on_write='true' AND
compaction_strategy_class='SizeTieredCompactionStrategy' AND
compression_parameters:sstable_compression='SnappyCompressor';
{noformat}
I can create a cf in cql3 and then use describe cf to get the above output.
However trying to run that create statement says that all of the following
are invalid options:
* default_validation
* min_compaction_threshold
* max_compaction_threshold
* comparator
--
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-4634) cqlsh --color option doesn't allow you to disable colors
[
https://issues.apache.org/jira/browse/CASSANDRA-4634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13452330#comment-13452330
]
paul cannon commented on CASSANDRA-4634:
+1
cqlsh --color option doesn't allow you to disable colors
Key: CASSANDRA-4634
URL: https://issues.apache.org/jira/browse/CASSANDRA-4634
Project: Cassandra
Issue Type: Bug
Components: Drivers
Reporter: Tyler Hobbs
Assignee: Tyler Hobbs
Priority: Trivial
Attachments: 4634-color-option.txt, 4634-color-option-v2.txt
There's no way to disable colors with cqlsh, despite it having a {{--color}}
option, because that option can only enable color if present, not disable it,
and the default is that color is enabled.
(Incidentally, if the {{--file}} option is used, it will disable color.)
--
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-4634) cqlsh --color option doesn't allow you to disable colors
[
https://issues.apache.org/jira/browse/CASSANDRA-4634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13451443#comment-13451443
]
paul cannon commented on CASSANDRA-4634:
Since I'm not a particular fan of ls/grep's command-line color control (too
much typing for cases which are fairly common) and since this isn't backwards
compatible (using {{\--color}} alone will give an error), I'm inclined to vote
-1 on it. Can we just add a {{\--no-color}} option to force color off for the
people who don't want to do {{TERM=dumb}} or {{cqlsh | cat}} or something?
cqlsh --color option doesn't allow you to disable colors
Key: CASSANDRA-4634
URL: https://issues.apache.org/jira/browse/CASSANDRA-4634
Project: Cassandra
Issue Type: Bug
Components: Drivers
Reporter: Tyler Hobbs
Assignee: Tyler Hobbs
Priority: Trivial
Attachments: 4634-color-option.txt
There's no way to disable colors with cqlsh, despite it having a {{--color}}
option, because that option can only enable color if present, not disable it,
and the default is that color is enabled.
(Incidentally, if the {{--file}} option is used, it will disable color.)
--
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-4582) in cqlsh the output of describe columnfamily doesn't convert to hex
[ https://issues.apache.org/jira/browse/CASSANDRA-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13451445#comment-13451445 ] paul cannon commented on CASSANDRA-4582: It's not. But the whole problem doesn't exist in cql3 (all column names are utf8 there). in cqlsh the output of describe columnfamily doesn't convert to hex --- Key: CASSANDRA-4582 URL: https://issues.apache.org/jira/browse/CASSANDRA-4582 Project: Cassandra Issue Type: Bug Reporter: Jeremy Hanna Assignee: paul cannon Priority: Minor Labels: cqlsh When the comparator=blob, cqlsh is outputting the metadata for column names in utf8. Instead it should output them in hex because that's what will make it so its output can be used to re-create the column family. Granted it's going to be pretty unreadable for the user, but it will work to re-create the CF. -- 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-4627) support inet data type
[ https://issues.apache.org/jira/browse/CASSANDRA-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13451487#comment-13451487 ] paul cannon commented on CASSANDRA-4627: Turns out this only required an update to the python-cql driver. Once a new release is out I'll update the bundled version in lib/. support inet data type -- Key: CASSANDRA-4627 URL: https://issues.apache.org/jira/browse/CASSANDRA-4627 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.2.0 beta 1 Reporter: paul cannon Assignee: paul cannon Labels: cql, cqlsh Fix For: 1.2.0 CASSANDRA-4018 introduced a new cassandra data type with a cql name inet, which is not yet supported in cqlsh. Add support for decoding and formatting. -- 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] [Assigned] (CASSANDRA-4362) cqlsh can't display reversed type values properly
[ https://issues.apache.org/jira/browse/CASSANDRA-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon reassigned CASSANDRA-4362: -- Assignee: paul cannon cqlsh can't display reversed type values properly - Key: CASSANDRA-4362 URL: https://issues.apache.org/jira/browse/CASSANDRA-4362 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1.1 Reporter: Ahmet AKYOL Assignee: paul cannon Priority: Minor Labels: cqlsh Here is table and data: CREATE TABLE t1 ( a int, b bigint, c varchar, d varchar, PRIMARY KEY (a,b,c) ) WITH CLUSTERING ORDER BY (b DESC, c DESC); INSERT INTO db.t1 (a,b,c,d) VALUES (1,10,'u1','s1'); INSERT INTO db.t1 (a,b,c,d) VALUES (1,15,'u1','d1'); INSERT INTO db.t1 (a,b,c,d) VALUES (1,21,'u3','ghfgh f1g'); INSERT INTO db.t1 (a,b,c,d) VALUES (1,31,'u2','1gh'); INSERT INTO db.t1 (a,b,c,d) VALUES (1,41,'u3','fgh1'); And here's the query cqlsh:db SELECT * FROM t1; a | b| c | d ---+--++--- 1 |\x00\x00\x00\x00\x00\x00\x00) | u3 | fgh1 1 | \x00\x00\x00\x00\x00\x00\x00\x1f | u2 | 1gh 1 | \x00\x00\x00\x00\x00\x00\x00\x15 | u3 | ghfgh f1g 1 | \x00\x00\x00\x00\x00\x00\x00\x0f | u1 |d1 1 | \x00\x00\x00\x00\x00\x00\x00\n | u1 |s1 As you can see, cqlsh can't display reversed type values properly ... -- 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-4362) cqlsh can't display reversed type values properly
[ https://issues.apache.org/jira/browse/CASSANDRA-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-4362: --- Fix Version/s: 1.2.0 Since the python-cql driver supports parametrized types as of its 1.1 version, it is now trivial to teach it how to deal with ReversedType. I've done that in the driver, and once we get a new release into cassandra this should be fixed for cassandra 1.2. cqlsh can't display reversed type values properly - Key: CASSANDRA-4362 URL: https://issues.apache.org/jira/browse/CASSANDRA-4362 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1.1 Reporter: Ahmet AKYOL Assignee: paul cannon Priority: Minor Labels: cqlsh Fix For: 1.2.0 Here is table and data: CREATE TABLE t1 ( a int, b bigint, c varchar, d varchar, PRIMARY KEY (a,b,c) ) WITH CLUSTERING ORDER BY (b DESC, c DESC); INSERT INTO db.t1 (a,b,c,d) VALUES (1,10,'u1','s1'); INSERT INTO db.t1 (a,b,c,d) VALUES (1,15,'u1','d1'); INSERT INTO db.t1 (a,b,c,d) VALUES (1,21,'u3','ghfgh f1g'); INSERT INTO db.t1 (a,b,c,d) VALUES (1,31,'u2','1gh'); INSERT INTO db.t1 (a,b,c,d) VALUES (1,41,'u3','fgh1'); And here's the query cqlsh:db SELECT * FROM t1; a | b| c | d ---+--++--- 1 |\x00\x00\x00\x00\x00\x00\x00) | u3 | fgh1 1 | \x00\x00\x00\x00\x00\x00\x00\x1f | u2 | 1gh 1 | \x00\x00\x00\x00\x00\x00\x00\x15 | u3 | ghfgh f1g 1 | \x00\x00\x00\x00\x00\x00\x00\x0f | u1 |d1 1 | \x00\x00\x00\x00\x00\x00\x00\n | u1 |s1 As you can see, cqlsh can't display reversed type values properly ... -- 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] [Resolved] (CASSANDRA-4336) CQLSH output formatting
[ https://issues.apache.org/jira/browse/CASSANDRA-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon resolved CASSANDRA-4336. Resolution: Duplicate Dupe of CASSANDRA-3756. CQLSH output formatting --- Key: CASSANDRA-4336 URL: https://issues.apache.org/jira/browse/CASSANDRA-4336 Project: Cassandra Issue Type: New Feature Components: Tools Environment: Any Reporter: Leonid Ilyevsky Priority: Minor Need to allow some sort of specification of the data output in cqlsh. Particularly precision of the floating numbers (currently it defaults to 3 significant digits, this is too low). -- 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] [Assigned] (CASSANDRA-4437) cqlsh displays bad timezone for timestamp types
[ https://issues.apache.org/jira/browse/CASSANDRA-4437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon reassigned CASSANDRA-4437: -- Assignee: paul cannon cqlsh displays bad timezone for timestamp types --- Key: CASSANDRA-4437 URL: https://issues.apache.org/jira/browse/CASSANDRA-4437 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1.2 Environment: Ubuntu 10.04 64bit Reporter: Emmanuel Courreges Assignee: paul cannon Priority: Minor cqlsh uses the time.localtime(epoch) function in python which converts the time received from thrift into your local timezone but does not fill in the timezone info, so when it is printed with time.strftime, it always appears with an hour in your timezone with + as the timezone which is wrong. Example: cqlsh:ecourreges UPDATE syndic set emails=11, unreadmails=3, nextuid=16, endwnd='2012-07-14 21:15:00+', endsub='2012-07-14 21:15:00+' where ise='ise1'; cqlsh:ecourreges select * from syndic; ise | alllastdetails | allmaildetails | emails | endsub | endwnd | lastdetails | lastnotif | maildetails | nextuid | unreadmails --++++--+--+-+---+-+-+- ise1 | null | null | 11 | 2012-07-14 23:15:00+ | 2012-07-14 23:15:00+ |null | null |null | 16 | 3 The output should be '2012-07-14 21:15:00+' or '2012-07-14 23:15:00+0200' but not '2012-07-14 23:15:00+' !!! I see 2 ways of fixing it: cqlsh line 474: replace timestamp = time.localtime(val) with timestamp = time.gmtime(val) or handle the timezone properly by using something else than localtime+strftime, but the question is what? Good luck and keep up the great work! Regards, Emmanuel Courrèges. Alten Consultant for Orange Portal France. -- 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-4437) cqlsh displays bad timezone for timestamp types
[
https://issues.apache.org/jira/browse/CASSANDRA-4437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13451505#comment-13451505
]
paul cannon commented on CASSANDRA-4437:
Hmm, {{time.strftime()}} should be filling in the local timezone for the {{%z}}
directive, so it should be correct as written. And it does work as intended on
my Debian and OS X boxes. However, it looks like you're right, it's not
behaving correctly in Ubuntu 10.04. Looking deeper, I can find a bunch of
OS/Python version pairs where it works correctly, and several where it doesn't.
The system libc strftime() appears to work as designed in all cases, so it
looks like a bug in (older?) Python versions.
Either way, I guess cqlsh can't rely on strftime to get that right.
cqlsh displays bad timezone for timestamp types
---
Key: CASSANDRA-4437
URL: https://issues.apache.org/jira/browse/CASSANDRA-4437
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.1.2
Environment: Ubuntu 10.04 64bit
Reporter: Emmanuel Courreges
Assignee: paul cannon
Priority: Minor
cqlsh uses the time.localtime(epoch) function in python which converts the
time received from thrift into your local timezone but does not fill in the
timezone info, so when it is printed with time.strftime, it always appears
with an hour in your timezone with + as the timezone which is wrong.
Example:
cqlsh:ecourreges UPDATE syndic set emails=11, unreadmails=3, nextuid=16,
endwnd='2012-07-14 21:15:00+', endsub='2012-07-14 21:15:00+' where
ise='ise1';
cqlsh:ecourreges select * from syndic;
ise | alllastdetails | allmaildetails | emails | endsub |
endwnd | lastdetails | lastnotif | maildetails | nextuid |
unreadmails
--++++--+--+-+---+-+-+-
ise1 | null | null | 11 | 2012-07-14 23:15:00+ |
2012-07-14 23:15:00+ |null | null |null | 16 |
3
The output should be '2012-07-14 21:15:00+' or '2012-07-14 23:15:00+0200'
but not '2012-07-14 23:15:00+' !!!
I see 2 ways of fixing it:
cqlsh line 474: replace timestamp = time.localtime(val) with timestamp =
time.gmtime(val)
or handle the timezone properly by using something else than
localtime+strftime, but the question is what?
Good luck and keep up the great work!
Regards,
Emmanuel Courrèges.
Alten Consultant for Orange Portal France.
--
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-4480) Binary protocol: adds events push
[ https://issues.apache.org/jira/browse/CASSANDRA-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450196#comment-13450196 ] paul cannon commented on CASSANDRA-4480: Okay, everything looks good at this point, except that when I stop an existing node and start it again, I still receive a TOPOLOGY_CHANGE - NEW_NODE event after the two STATUS_CHANGE - UP events, even though the up'd node was previously known. Binary protocol: adds events push -- Key: CASSANDRA-4480 URL: https://issues.apache.org/jira/browse/CASSANDRA-4480 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.0 Attachments: 4480.txt, 4480-v2.txt Clients needs to know about a number of cluster changes (new/removed nodes typically) to function properly. With the binary protocol we could start pushing such events to the clients directly. The basic idea would be that a client would register to a number of events and would then receive notifications when those happened. I could at least the following events be useful to clients: * Addition and removal of nodes * Schema changes (otherwise clients would have to pull schema all the time to know that say a new column has been added) * node up/dow events (down events might not be too useful, but up events could be helpful). The main problem I can see with that is that we want to make it clear that clients are supposed to register for events on only one or two of their connections (total, not per-host), otherwise it'll be just flooding. One solution to make it much more unlikely that this happen could be to distinguish two kinds of connections: Data and Control (could just a simple flag with the startup message for instance). Data connections would not allow registering to events and Control ones would allow it but wouldn't allow queries. I.e. clients would have to dedicate a connection to those events, but that's likely the only sane way to do it anyway. -- 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-3979) Consider providing error code with exceptions (and documenting them)
[ https://issues.apache.org/jira/browse/CASSANDRA-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450225#comment-13450225 ] paul cannon commented on CASSANDRA-3979: Ok to close this one? Consider providing error code with exceptions (and documenting them) Key: CASSANDRA-3979 URL: https://issues.apache.org/jira/browse/CASSANDRA-3979 Project: Cassandra Issue Type: Sub-task Components: API Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Labels: cql3 Fix For: 1.2.0 beta 1 It could be a good idea to assign documented error code for the different exception raised. Currently, one may have to parse the exception string (say if one wants to know if its 'create keyspace' failed because the keyspace already exists versus other kind of exception), but it means we cannot improve the error message at the risk of breaking client code. Adding documented error codes with the message would avoid this. -- 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-4539) potential backwards incompatibility in native protocol
[
https://issues.apache.org/jira/browse/CASSANDRA-4539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450286#comment-13450286
]
paul cannon commented on CASSANDRA-4539:
+1.
potential backwards incompatibility in native protocol
--
Key: CASSANDRA-4539
URL: https://issues.apache.org/jira/browse/CASSANDRA-4539
Project: Cassandra
Issue Type: Improvement
Components: API
Affects Versions: 1.2.0 beta 1
Reporter: paul cannon
Assignee: Sylvain Lebresne
Priority: Minor
Labels: cql, native_protocol
Fix For: 1.2.0 beta 1
Attachments: 4539.txt
In the text of the native_protocol.spec document, it explains the format for
a notation called {{[option]}}, which should represent {{a pair of
idvalue}}.
In doing a first-draft implementation of the protocol for the python driver,
though, I found that I had a misunderstanding. I read that section as saying
that {{value}} was a {{[value]}}, and that it could have a length of 0
(i.e., the {{[int]}} on the front of the {{[value]}} could be 0). However, it
turns out that {{value}} might not be there at all, or might be *two*
{{[value]}}'s, depending on the option id and message context.
I'm not a fan of this, since
* A protocol parsing library can't simply implement a single function to
read in {{[option]}}'s, since the length of the value part is dependent on
the message context
* If we add a new native data type (a new option id which could be used
inside a {{col_spec_i}} in a RESULT message), then older clients will not
know how to read past the value part. Of course they won't know how to
interpret the data or deserialize later rows of that unknown type - that's
not the problem - the problem is that the older client should be able just to
mark that column as unparseable and still handle the rest of the columns.
Can we make {{value}} be a {{[value]}}, the contents of which can be
re-interpreted as a {{[string]}}, an {{[option]}}, two {{[option]}}'s, or
whatever?
--
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] [Resolved] (CASSANDRA-4582) in cqlsh the output of describe columnfamily doesn't convert to hex
[ https://issues.apache.org/jira/browse/CASSANDRA-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon resolved CASSANDRA-4582. Resolution: Won't Fix I'd like to implement this fix, but it's a little less trivial than it sounds to do this in a general way for all comparator classes- cqlsh needs to decode the binary column names according to the comparator class (easy), and then translate the native python values back into a textual format that CQL will parse correctly for a value of the original class (not as easy). The machinery to do that sort of thing is in the trunk (1.2) branch, but it's not in 1.1, and since this only applies to certain cql2 cases, it doesn't seem like it would be as useful to put only in cassandra 1.2. Affecting the usefulness even further is the fact that it seems to be rare to put explicit column names in a cfdef's column_metadata when the column names use a non-textual comparator type (where one usually uses wide rows, not pre-defined columns). I could backport the more powerful translation machinery to 1.1, but it would aggravate the already-somewhat-hairy merging situation for cqlsh. We could also just make this change for comparator=blob and not for the others, but it doesn't seem clear to me that this would be any more useful for blob than, say, timeuuid or float or whatever. Therefore, I'll close this ticket for now; if anyone still feels strongly about the need and has more convincing input on use cases, we can open it back up. in cqlsh the output of describe columnfamily doesn't convert to hex --- Key: CASSANDRA-4582 URL: https://issues.apache.org/jira/browse/CASSANDRA-4582 Project: Cassandra Issue Type: Bug Reporter: Jeremy Hanna Assignee: paul cannon Priority: Minor Labels: cqlsh When the comparator=blob, cqlsh is outputting the metadata for column names in utf8. Instead it should output them in hex because that's what will make it so its output can be used to re-create the column family. Granted it's going to be pretty unreadable for the user, but it will work to re-create the CF. -- 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-4594) COPY TO and COPY FROM don't default to consistent ordering of columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon updated CASSANDRA-4594:
---
Fix Version/s: (was: 1.2.0)
1.1.6
COPY TO and COPY FROM don't default to consistent ordering of columns
-
Key: CASSANDRA-4594
URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
Project: Cassandra
Issue Type: Bug
Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor
Fix For: 1.1.6
Here is the input:
{code}
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
USE test;
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
COPY airplanes TO 'temp.cfg' WITH HEADER=true;
TRUNCATE airplanes;
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
SELECT * FROM airplanes;
{code}
Here is what happens when executed. Note how it tried to import the float
into the int column:
{code}
cqlsh:test DROP KEYSPACE test;
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
cqlsh:test USE test;
cqlsh:test
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,
... manufacturer ascii,
... year int,
... mach float
... );
cqlsh:test
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
1 rows exported in 0.003 seconds.
cqlsh:test TRUNCATE airplanes;
cqlsh:test
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'
Aborting import at record #0 (line 1). Previously-inserted values still
present.
0 rows imported in 0.002 seconds.
{code}
--
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-4594) COPY TO and COPY FROM don't default to consistent ordering of columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450322#comment-13450322
]
paul cannon commented on CASSANDRA-4594:
Seems worth it to fix this in the 1.1 branch too.
COPY TO and COPY FROM don't default to consistent ordering of columns
-
Key: CASSANDRA-4594
URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
Project: Cassandra
Issue Type: Bug
Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor
Fix For: 1.1.6
Here is the input:
{code}
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
USE test;
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
COPY airplanes TO 'temp.cfg' WITH HEADER=true;
TRUNCATE airplanes;
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
SELECT * FROM airplanes;
{code}
Here is what happens when executed. Note how it tried to import the float
into the int column:
{code}
cqlsh:test DROP KEYSPACE test;
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
cqlsh:test USE test;
cqlsh:test
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,
... manufacturer ascii,
... year int,
... mach float
... );
cqlsh:test
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
1 rows exported in 0.003 seconds.
cqlsh:test TRUNCATE airplanes;
cqlsh:test
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'
Aborting import at record #0 (line 1). Previously-inserted values still
present.
0 rows imported in 0.002 seconds.
{code}
--
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-4627) support inet data type
paul cannon created CASSANDRA-4627: -- Summary: support inet data type Key: CASSANDRA-4627 URL: https://issues.apache.org/jira/browse/CASSANDRA-4627 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.2.0 beta 1 Reporter: paul cannon Assignee: paul cannon Fix For: 1.2.0 CASSANDRA-4018 introduced a new cassandra data type with a cql name inet, which is not yet supported in cqlsh. Add support for decoding and formatting. -- 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-4480) Binary protocol: adds events push
[ https://issues.apache.org/jira/browse/CASSANDRA-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448511#comment-13448511 ] paul cannon commented on CASSANDRA-4480: I don't think Jonathan cares much, and although I still don't like the mode separation, I'd rather have this committed sooner than later, and I don't want to take up your time, so let's just go with it. So the other minor things I've seen with this patch are: * The doc implies that the status_change, topology_change, new_node, up, etc strings are lowercase, but they're sent in uppercase. We should probably document that the case could be upper, or that they could be in either case, or change to sending lowercase. * In my tests using ccm (with a subsequent ccm add), the STATUS_CHANGE - UP event notification appears to be sent twice. Probably it doesn't matter for any practical purpose, but I mention it in case it's indicative of a bug. * This probably isn't isolated to this change, but I noticed it here: when something results in an error message on the native protocol, the resulting error message does not have a matching stream-id for the corresponding request. Makes it hard to send back to the right place. Binary protocol: adds events push -- Key: CASSANDRA-4480 URL: https://issues.apache.org/jira/browse/CASSANDRA-4480 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.0 Attachments: 4480.txt Clients needs to know about a number of cluster changes (new/removed nodes typically) to function properly. With the binary protocol we could start pushing such events to the clients directly. The basic idea would be that a client would register to a number of events and would then receive notifications when those happened. I could at least the following events be useful to clients: * Addition and removal of nodes * Schema changes (otherwise clients would have to pull schema all the time to know that say a new column has been added) * node up/dow events (down events might not be too useful, but up events could be helpful). The main problem I can see with that is that we want to make it clear that clients are supposed to register for events on only one or two of their connections (total, not per-host), otherwise it'll be just flooding. One solution to make it much more unlikely that this happen could be to distinguish two kinds of connections: Data and Control (could just a simple flag with the startup message for instance). Data connections would not allow registering to events and Control ones would allow it but wouldn't allow queries. I.e. clients would have to dedicate a connection to those events, but that's likely the only sane way to do it anyway. -- 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-4488) update cqlsh recognized syntax (for tab completion, etc)
[ https://issues.apache.org/jira/browse/CASSANDRA-4488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13449242#comment-13449242 ] paul cannon commented on CASSANDRA-4488: Also CASSANDRA-4497 and CASSANDRA-4490, if it gets in. update cqlsh recognized syntax (for tab completion, etc) Key: CASSANDRA-4488 URL: https://issues.apache.org/jira/browse/CASSANDRA-4488 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: paul cannon Assignee: paul cannon Priority: Minor Fix For: 1.1.6 cqlsh syntax awareness (tab completion, etc) should be aware of several recent changes to CQL: * CASSANDRA-4179 (row key and column value composites; 1.2 only) * CASSANDRA-3647 (sets/lists/maps; 1.2 only) * CASSANDRA-4018 (inet type; 1.2 only) * CASSANDRA-4278 (hyphens in keyspace properties; 1.1 and up) * CASSANDRA-4217 (accessing ttl, timestamp; 1.1 and up) -- 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-4480) Binary protocol: adds events push
[ https://issues.apache.org/jira/browse/CASSANDRA-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447369#comment-13447369 ] paul cannon commented on CASSANDRA-4480: I do see what you mean, and it isn't especially inefficient to have lots of extra messages in that worst case, but again, those events should be very rare (under normal production conditions, well under one per day) and they're really small and are practically free to process. The complexity on the client side probably wouldn't be very bad, like you say. An example case where the extra complexity is at least noticeable is a driver which, for whatever reason, only needs a single connection at a time to the cluster. Cqlsh, opscenter-agents, and other utility type apps are possible instances where that would be the case. Before now, that was perfectly doable, especially with the new async capabilities. Adding the requirement for a second connection means either doubling up or abstracting the connection-maintenance code (recognize when a connection goes down or is stalled, reconnecting to the appropriate place, etc) and being able to handle odd error cases, like when authentication and setup succeeds on one connection but not on the other, etc. The main downside I see to making the change is that it would use up more of your time :), and that would suck, so I'll leave it up to you. Binary protocol: adds events push -- Key: CASSANDRA-4480 URL: https://issues.apache.org/jira/browse/CASSANDRA-4480 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.0 Attachments: 4480.txt Clients needs to know about a number of cluster changes (new/removed nodes typically) to function properly. With the binary protocol we could start pushing such events to the clients directly. The basic idea would be that a client would register to a number of events and would then receive notifications when those happened. I could at least the following events be useful to clients: * Addition and removal of nodes * Schema changes (otherwise clients would have to pull schema all the time to know that say a new column has been added) * node up/dow events (down events might not be too useful, but up events could be helpful). The main problem I can see with that is that we want to make it clear that clients are supposed to register for events on only one or two of their connections (total, not per-host), otherwise it'll be just flooding. One solution to make it much more unlikely that this happen could be to distinguish two kinds of connections: Data and Control (could just a simple flag with the startup message for instance). Data connections would not allow registering to events and Control ones would allow it but wouldn't allow queries. I.e. clients would have to dedicate a connection to those events, but that's likely the only sane way to do it anyway. -- 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-4480) Binary protocol: adds events push
[ https://issues.apache.org/jira/browse/CASSANDRA-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447372#comment-13447372 ] paul cannon commented on CASSANDRA-4480: Just optional unless you want push features. But I think most clients will want push features. Binary protocol: adds events push -- Key: CASSANDRA-4480 URL: https://issues.apache.org/jira/browse/CASSANDRA-4480 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.0 Attachments: 4480.txt Clients needs to know about a number of cluster changes (new/removed nodes typically) to function properly. With the binary protocol we could start pushing such events to the clients directly. The basic idea would be that a client would register to a number of events and would then receive notifications when those happened. I could at least the following events be useful to clients: * Addition and removal of nodes * Schema changes (otherwise clients would have to pull schema all the time to know that say a new column has been added) * node up/dow events (down events might not be too useful, but up events could be helpful). The main problem I can see with that is that we want to make it clear that clients are supposed to register for events on only one or two of their connections (total, not per-host), otherwise it'll be just flooding. One solution to make it much more unlikely that this happen could be to distinguish two kinds of connections: Data and Control (could just a simple flag with the startup message for instance). Data connections would not allow registering to events and Control ones would allow it but wouldn't allow queries. I.e. clients would have to dedicate a connection to those events, but that's likely the only sane way to do it anyway. -- 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-4606) Add Recommends: ntp to Debian packages
paul cannon created CASSANDRA-4606: -- Summary: Add Recommends: ntp to Debian packages Key: CASSANDRA-4606 URL: https://issues.apache.org/jira/browse/CASSANDRA-4606 Project: Cassandra Issue Type: Improvement Components: Packaging Reporter: paul cannon Assignee: paul cannon Priority: Minor Fix For: 1.1.5, 1.2.0 NTP is important enough in correct operation of a cassandra cluster that we should at least Recommend it. -- 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-4606) Add Recommends: ntp to Debian packages
[ https://issues.apache.org/jira/browse/CASSANDRA-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-4606: --- Attachment: 4606.patch.txt This applies to both the 1.1 and trunk branches. Add Recommends: ntp to Debian packages -- Key: CASSANDRA-4606 URL: https://issues.apache.org/jira/browse/CASSANDRA-4606 Project: Cassandra Issue Type: Improvement Components: Packaging Reporter: paul cannon Assignee: paul cannon Priority: Minor Labels: debian, packaging Fix For: 1.1.5, 1.2.0 Attachments: 4606.patch.txt NTP is important enough in correct operation of a cassandra cluster that we should at least Recommend it. -- 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-4500) cqlsh: understand updated encodings for collections
[ https://issues.apache.org/jira/browse/CASSANDRA-4500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13446755#comment-13446755 ] paul cannon commented on CASSANDRA-4500: Looks like you missed removing the old lib/cql-internal-only-1.0.10.zip from the repo. Shouldn't matter, cqlsh should pick the lexicographically highest one, but the old one won't be used for anything. cqlsh: understand updated encodings for collections --- Key: CASSANDRA-4500 URL: https://issues.apache.org/jira/browse/CASSANDRA-4500 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.2.0 beta 1 Reporter: paul cannon Assignee: paul cannon Labels: cqlsh Fix For: 1.2.0 beta 1 Attachments: 4500.patch.txt After CASSANDRA-4453, collections will be represented using the binary encoding in thrift CqlResults instead of json. Update cqlsh (and python-cql as necessary) to support. -- 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-4500) cqlsh: understand updated encodings for collections
[ https://issues.apache.org/jira/browse/CASSANDRA-4500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13445709#comment-13445709 ] paul cannon commented on CASSANDRA-4500: Updated internal driver zip to 1.1.0 final. Updated version is in my github, same branch (4500), new version tagged pending/4500-3. cqlsh: understand updated encodings for collections --- Key: CASSANDRA-4500 URL: https://issues.apache.org/jira/browse/CASSANDRA-4500 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.2.0 beta 1 Reporter: paul cannon Assignee: paul cannon Labels: cqlsh Fix For: 1.2.0 Attachments: 4500.patch.txt After CASSANDRA-4453, collections will be represented using the binary encoding in thrift CqlResults instead of json. Update cqlsh (and python-cql as necessary) to support. -- 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-4497) Update CQL pseudo-maps to real maps
[ https://issues.apache.org/jira/browse/CASSANDRA-4497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13446178#comment-13446178 ] paul cannon commented on CASSANDRA-4497: From the patch, it looks like we won't be supporting the old syntax anymore. This, and the option name changes, is going to make all our docs more complicated, and also non-trivially complicate the smarter clients (in particular, cqlsh, opscenter, etc). Also, it looks like there isn't any way to change one option and leave the other intact (like WITH replication['replication_factor'] = 2, which it seems like ought to be implied by the use of the map syntax. The whole thing doesn't seem much cleaner than before. What's the main motivation? Update CQL pseudo-maps to real maps --- Key: CASSANDRA-4497 URL: https://issues.apache.org/jira/browse/CASSANDRA-4497 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Labels: cql3 Fix For: 1.2.0 beta 1 Attachments: CASSANDRA-4497.patch - compression_parameters - replication_parameters (combine strategy + options like we did compression) - anything else? -- 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-4497) Update CQL pseudo-maps to real maps
[ https://issues.apache.org/jira/browse/CASSANDRA-4497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13446584#comment-13446584 ] paul cannon commented on CASSANDRA-4497: bq. How is it more complicated to document that replication_parameters is a map like any other, than replication_parameters has its own one-off syntax that only exists for historical reasons? I don't buy it. It's not, but it is more complicated when we need to say if you're using CQL 3 with Cassandra 1.0 or 1.1, then you need to do this. If you're using CQL 3 with 1.2 or higher, then you need to do this totally different thing. If you're using CQL 2, then you do something else. I know, ideally we would have fully separate documentation sets and fully separate cqlsh versions per major Cassandra version, but people don't seem to be very good at referring only to the right one. bq. reduce the special case weirdnesses exposed to users, as above I'm admittedly thick, but which weirdnesses are reduced here? bq. reduce special case weirdnesses in our internal implementation (which is also exposed to power users in the system KS). so much more pleasant to select replication_options from schema_keyspaces where keyspace_name = 'foo' and get a Map back. I agree with that 100%, but this patch doesn't do that. It only changes the dedicated syntax for setting keyspace and columnfamily options. I'd much prefer getting real maps inside the system.schema* tables and leaving the cql syntax alone when we can. It has been a real moving target, and swiping out the first command you do from under everyone's feet seems like it might be discouraging. Update CQL pseudo-maps to real maps --- Key: CASSANDRA-4497 URL: https://issues.apache.org/jira/browse/CASSANDRA-4497 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Labels: cql3 Fix For: 1.2.0 beta 1 Attachments: CASSANDRA-4497.patch - compression_parameters - replication_parameters (combine strategy + options like we did compression) - anything else? -- 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-4594) COPY TO and COPY FROM don't default to consistent ordering of columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13445584#comment-13445584
]
paul cannon commented on CASSANDRA-4594:
This is because a {{select * from airplanes;}} does not give the columns in the
order they were defined. I'm not sure why not; if that's a bug in C*, then we
should fix that. If there isn't supposed to be any expectation of order, then
cqlsh should be inspecting the columns and specifying them explicitly.
COPY TO and COPY FROM don't default to consistent ordering of columns
-
Key: CASSANDRA-4594
URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
Project: Cassandra
Issue Type: Bug
Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor
Here is the input:
{code}
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
USE test;
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
COPY airplanes TO 'temp.cfg' WITH HEADER=true;
TRUNCATE airplanes;
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
SELECT * FROM airplanes;
{code}
Here is what happens when executed. Note how it tried to import the float
into the int column:
{code}
cqlsh:test DROP KEYSPACE test;
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
cqlsh:test USE test;
cqlsh:test
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,
... manufacturer ascii,
... year int,
... mach float
... );
cqlsh:test
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
1 rows exported in 0.003 seconds.
cqlsh:test TRUNCATE airplanes;
cqlsh:test
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'
Aborting import at record #0 (line 1). Previously-inserted values still
present.
0 rows imported in 0.002 seconds.
{code}
--
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-3979) Consider providing error code with exceptions (and documenting them)
[ https://issues.apache.org/jira/browse/CASSANDRA-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13444605#comment-13444605 ] paul cannon commented on CASSANDRA-3979: +1 on this monster. This will be fantastic for clients, and should encourage use of the binary protocol. I did have to make a really small change to the 'stress' tool code to get a full successful build, as shown here: https://github.com/thepaul/cassandra/commit/7b1f71f6 , but that's a triviality. The only other thing is that it would have been nice to include the extra information for Thrift clients too- even if it's just rendered into the error string. But maybe that would break super-fragile clients that depend on exact error messages? Consider providing error code with exceptions (and documenting them) Key: CASSANDRA-3979 URL: https://issues.apache.org/jira/browse/CASSANDRA-3979 Project: Cassandra Issue Type: Sub-task Components: API Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Labels: cql3 Fix For: 1.2.0 beta 1 It could be a good idea to assign documented error code for the different exception raised. Currently, one may have to parse the exception string (say if one wants to know if its 'create keyspace' failed because the keyspace already exists versus other kind of exception), but it means we cannot improve the error message at the risk of breaking client code. Adding documented error codes with the message would avoid this. -- 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-4498) Remove openjdk-6-jre Cassandra APT dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13444606#comment-13444606 ] paul cannon commented on CASSANDRA-4498: If there's no other problems with installing openjdk-6-jre on the side, then definitely +1 for status quo. Remove openjdk-6-jre Cassandra APT dependencies --- Key: CASSANDRA-4498 URL: https://issues.apache.org/jira/browse/CASSANDRA-4498 Project: Cassandra Issue Type: Improvement Reporter: Terrance Shepherd Assignee: Brandon Williams Priority: Minor Labels: debian Fix For: 1.2.0 beta 1 Attachments: apache_cassandra_Packages.diff As it is well known the recommended jre for Cassandra is sun java 1.6 but at this point that package no longer in the debian or ubuntu apt repos. In order to run Cassandra with the sun java 1.6 jre it must be installed manually with out the repos. Because of this when you install cassandra via the apache or datastax apt repos it must also install openjdk-6-jre even though sun java 1.6 jre is already installed. I would suggest that the java apt dependencies be removed from the Depends field in package configuration and move to either the Recommends or Suggests field so that way openjdk is not being downloaded when not necessary and possibly interfering with a be pre-installed jre -- 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-4480) Binary protocol: adds events push
[ https://issues.apache.org/jira/browse/CASSANDRA-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13444642#comment-13444642 ] paul cannon commented on CASSANDRA-4480: I don't think I like the split of 'control' and 'data' modes. Why can't the client library relegate the REGISTER/EVENT messages to a single connection, if the user wants it that way? This seems like it adds needless complexity on both sides. In the very worst case, if we remove the restriction, a few dozen connections get an extra ~40-byte message once per (rare) topology/node-status change when only one would have sufficed. Is that really that much of a problem? Binary protocol: adds events push -- Key: CASSANDRA-4480 URL: https://issues.apache.org/jira/browse/CASSANDRA-4480 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.0 Attachments: 4480.txt Clients needs to know about a number of cluster changes (new/removed nodes typically) to function properly. With the binary protocol we could start pushing such events to the clients directly. The basic idea would be that a client would register to a number of events and would then receive notifications when those happened. I could at least the following events be useful to clients: * Addition and removal of nodes * Schema changes (otherwise clients would have to pull schema all the time to know that say a new column has been added) * node up/dow events (down events might not be too useful, but up events could be helpful). The main problem I can see with that is that we want to make it clear that clients are supposed to register for events on only one or two of their connections (total, not per-host), otherwise it'll be just flooding. One solution to make it much more unlikely that this happen could be to distinguish two kinds of connections: Data and Control (could just a simple flag with the startup message for instance). Data connections would not allow registering to events and Control ones would allow it but wouldn't allow queries. I.e. clients would have to dedicate a connection to those events, but that's likely the only sane way to do it anyway. -- 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-4579) CQL queries using LIMIT sometimes missing results
[
https://issues.apache.org/jira/browse/CASSANDRA-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442709#comment-13442709
]
paul cannon commented on CASSANDRA-4579:
Thanks to Christoph Hack for identifying the problem.
CQL queries using LIMIT sometimes missing results
-
Key: CASSANDRA-4579
URL: https://issues.apache.org/jira/browse/CASSANDRA-4579
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Reporter: paul cannon
Labels: cql, cql3
Fix For: 1.2.0
In certain conditions, CQL queries using LIMIT clauses are not being given
all of the expected results (whether unset column values or missing rows).
Here are the condition sets I've been able to identify:
First mode: all rows are returned, but in the last row of results, all
columns which are not part of the primary key receive no values, except for
the first non-primary-key column. Conditions:
* Table has a multi-component primary key
* Table has more than one column which is not a component of the primary key
* The number of results which would be returned by a query is equal to or
more than the specified LIMIT
Second mode: result has fewer rows than it should, lower than both the LIMIT
and the actual number of matching rows. Conditions:
* Table has a single-column primary key
* Table has more than one column which is not a component of the primary key
* The number of results which would be returned by a query is equal to or
more than the specified LIMIT
It would make sense to me that this would have started with CASSANDRA-4329,
but bisecting indicates that this behavior started with commit
91bdf7fb4220b27e9566c6673bf5dbd14153017c, implementing CASSANDRA-3647.
Test case for the first failure mode:
{noformat}
DROP KEYSPACE test;
CREATE KEYSPACE test
WITH strategy_class = 'SimpleStrategy'
AND strategy_options:replication_factor = 1;
USE test;
CREATE TABLE testcf (
a int,
b int,
c int,
d int,
e int,
PRIMARY KEY (a, b)
);
INSERT INTO testcf (a, b, c, d, e) VALUES (1, 11, 111, , 1);
INSERT INTO testcf (a, b, c, d, e) VALUES (2, 22, 222, , 2);
INSERT INTO testcf (a, b, c, d, e) VALUES (3, 33, 333, , 3);
INSERT INTO testcf (a, b, c, d, e) VALUES (4, 44, 444, , 4);
SELECT * FROM testcf;
SELECT * FROM testcf LIMIT 1; -- columns d and e in result row are null
SELECT * FROM testcf LIMIT 2; -- columns d and e in last result row are null
SELECT * FROM testcf LIMIT 3; -- columns d and e in last result row are null
SELECT * FROM testcf LIMIT 4; -- columns d and e in last result row are null
SELECT * FROM testcf LIMIT 5; -- results are correct (4 rows returned)
{noformat}
Test case for the second failure mode:
{noformat}
CREATE KEYSPACE test
WITH strategy_class = 'SimpleStrategy'
AND strategy_options:replication_factor = 1;
USE test;
CREATE TABLE testcf (
a int primary key,
b int,
c int,
);
INSERT INTO testcf (a, b, c) VALUES (1, 11, 111);
INSERT INTO testcf (a, b, c) VALUES (2, 22, 222);
INSERT INTO testcf (a, b, c) VALUES (3, 33, 333);
INSERT INTO testcf (a, b, c) VALUES (4, 44, 444);
SELECT * FROM testcf;
SELECT * FROM testcf LIMIT 1; -- gives 1 row
SELECT * FROM testcf LIMIT 2; -- gives 1 row
SELECT * FROM testcf LIMIT 3; -- gives 2 rows
SELECT * FROM testcf LIMIT 4; -- gives 2 rows
SELECT * FROM testcf LIMIT 5; -- gives 3 rows
{noformat}
--
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-4500) cqlsh: understand updated encodings for collections
[ https://issues.apache.org/jira/browse/CASSANDRA-4500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-4500: --- Attachment: 4500.patch.txt Changes attached in one squashed diff, if that's your cup of tea, or you can get it in somewhat more granular changes in the 4500 branch of my github: https://github.com/thepaul/cassandra/tree/4500 Current version is tagged pending/4500. You *do* need at least the updated driver (lib/cql-internal-only-1.1.0-beta1.zip) from the github version, if you are going to use the diff attached here, since diffs aren't so great for changes to binaries. cqlsh: understand updated encodings for collections --- Key: CASSANDRA-4500 URL: https://issues.apache.org/jira/browse/CASSANDRA-4500 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.2.0 Reporter: paul cannon Assignee: paul cannon Fix For: 1.2.0 Attachments: 4500.patch.txt After CASSANDRA-4453, collections will be represented using the binary encoding in thrift CqlResults instead of json. Update cqlsh (and python-cql as necessary) to support. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4546) cqlsh: handle when full cassandra type class names are given
[
https://issues.apache.org/jira/browse/CASSANDRA-4546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13436362#comment-13436362
]
paul cannon commented on CASSANDRA-4546:
It's not directly related. Just a minor problem with error reporting that came
up while I was testing this.
cqlsh: handle when full cassandra type class names are given
Key: CASSANDRA-4546
URL: https://issues.apache.org/jira/browse/CASSANDRA-4546
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.2.0
Reporter: paul cannon
Assignee: paul cannon
Labels: cqlsh
Fix For: 1.2.0
Attachments: 4546.patch.txt
When a builtin Cassandra type was being used for data in previous versions of
Cassandra, only the short name was sent: UTF8Type, TimeUUIDType, etc.
Starting with 1.2, as of CASSANDRA-4453, the full class names are sent.
Cqlsh doesn't know how to handle this, and is currently treating all data as
if it were an unknown type. This goes as far as to cause an exception when
the type is actually a number, because the driver deserializes it right, and
then cqlsh tries to use it as a string.
Here for googlage:
{noformat}
AttributeError: 'int' object has no attribute 'replace'
{noformat}
Fixeries are in order.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4539) potential backwards incompatibility in native protocol
paul cannon created CASSANDRA-4539:
--
Summary: potential backwards incompatibility in native protocol
Key: CASSANDRA-4539
URL: https://issues.apache.org/jira/browse/CASSANDRA-4539
Project: Cassandra
Issue Type: Improvement
Components: API
Affects Versions: 1.2
Reporter: paul cannon
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.2
In the text of the native_protocol.spec document, it explains the format for a
notation called {{[option]}}, which should represent {{a pair of
idvalue}}.
In doing a first-draft implementation of the protocol for the python driver,
though, I found that I had a misunderstanding. I read that section as saying
that {{value}} was a {{[value]}}, and that it could have a length of 0 (i.e.,
the {{[int]}} on the front of the {{[value]}} could be 0). However, it turns
out that {{value}} might not be there at all, or might be *two*
{{[value]}}'s, depending on the option id and message context.
I'm not a fan of this, since
* A protocol parsing library can't simply implement a single function to read
in {{[option]}}'s, since the length of the value part is dependent on the
message context
* If we add a new native data type (a new option id which could be used inside
a {{col_spec_i}} in a RESULT message), then older clients will not know how
to read past the value part. Of course they won't know how to interpret the
data or deserialize later rows of that unknown type - that's not the problem -
the problem is that the older client should be able just to mark that column as
unparseable and still handle the rest of the columns.
Can we make {{value}} be a {{[value]}}, the contents of which can be
re-interpreted as a {{[string]}}, an {{[option]}}, two {{[option]}}'s, or
whatever?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4453) Better support of collections in the binary protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13434538#comment-13434538 ] paul cannon commented on CASSANDRA-4453: Only a tiny nit here: might be worth removing the `o.a.c.cql3.ResultSet.Metadata.dataTypeCodec` static instance declaration, since it's unused now and could be a little confusing with `DataType.codec` serving the same purpose. Also- this is only somewhat related, but I came across it while testing and reviewing, and it might be a good place to shoehorn in an extra tweaks: The native_protocol.spec doc doesn't ever explicitly mention endianness. It's big-endian, network byte order, as probably everyone would expect, but it's still nice to make that clear. But yeah, +1. Better support of collections in the binary protocol Key: CASSANDRA-4453 URL: https://issues.apache.org/jira/browse/CASSANDRA-4453 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2 Attachments: 0001-Adds-generics-to-collection-types.txt, 0002-Support-collections-natively-in-the-binary-protocol.txt, 0003-Use-binary-format-for-thrift.txt Currently, collections results are serialized to json string and send that way. This doesn't feel right at all for the binary protocol and we should use a simple binary serialization of the collection instead. For the thrift protocol, we might want to keep the json serialization or use the same binary serialization. I don't really have much opinion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4539) potential backwards incompatibility in native protocol
[
https://issues.apache.org/jira/browse/CASSANDRA-4539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13434599#comment-13434599
]
paul cannon commented on CASSANDRA-4539:
Another potential problem is if a client program wants to use a STARTUP option
not yet understood by the driver. If an option's value part is always a
{{[value]}}, then the driver doesn't have to guess how to send that argument to
the server.
(It might also be worthwhile to make the values in STARTUP optionlists always
be {{[string]}} s, so that apps don't have to bother with potentially encoding
binary values themselves when the driver doesn't recognize those options.)
potential backwards incompatibility in native protocol
--
Key: CASSANDRA-4539
URL: https://issues.apache.org/jira/browse/CASSANDRA-4539
Project: Cassandra
Issue Type: Improvement
Components: API
Affects Versions: 1.2
Reporter: paul cannon
Assignee: Sylvain Lebresne
Priority: Minor
Labels: cql, native_protocol
Fix For: 1.2
In the text of the native_protocol.spec document, it explains the format for
a notation called {{[option]}}, which should represent {{a pair of
idvalue}}.
In doing a first-draft implementation of the protocol for the python driver,
though, I found that I had a misunderstanding. I read that section as saying
that {{value}} was a {{[value]}}, and that it could have a length of 0
(i.e., the {{[int]}} on the front of the {{[value]}} could be 0). However, it
turns out that {{value}} might not be there at all, or might be *two*
{{[value]}}'s, depending on the option id and message context.
I'm not a fan of this, since
* A protocol parsing library can't simply implement a single function to
read in {{[option]}}'s, since the length of the value part is dependent on
the message context
* If we add a new native data type (a new option id which could be used
inside a {{col_spec_i}} in a RESULT message), then older clients will not
know how to read past the value part. Of course they won't know how to
interpret the data or deserialize later rows of that unknown type - that's
not the problem - the problem is that the older client should be able just to
mark that column as unparseable and still handle the rest of the columns.
Can we make {{value}} be a {{[value]}}, the contents of which can be
re-interpreted as a {{[string]}}, an {{[option]}}, two {{[option]}}'s, or
whatever?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4546) cqlsh: handle when full cassandra type class names are given
paul cannon created CASSANDRA-4546:
--
Summary: cqlsh: handle when full cassandra type class names are
given
Key: CASSANDRA-4546
URL: https://issues.apache.org/jira/browse/CASSANDRA-4546
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.2
Reporter: paul cannon
Assignee: paul cannon
Fix For: 1.2
When a builtin Cassandra type was being used for data in previous versions of
Cassandra, only the short name was sent: UTF8Type, TimeUUIDType, etc.
Starting with 1.2, as of CASSANDRA-4453, the full class names are sent.
Cqlsh doesn't know how to handle this, and is currently treating all data as if
it were an unknown type. This goes as far as to cause an exception when the
type is actually a number, because the driver deserializes it right, and then
cqlsh tries to use it as a string.
Here for googlage:
{noformat}
AttributeError: 'int' object has no attribute 'replace'
{noformat}
Fixeries are in order.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4546) cqlsh: handle when full cassandra type class names are given
[
https://issues.apache.org/jira/browse/CASSANDRA-4546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon updated CASSANDRA-4546:
---
Attachment: 4546.patch.txt
Fix attached. Also available on the 4546 branch on my github- this version
tagged pending/4546:
https://github.com/thepaul/cassandra/tree/4546
cqlsh: handle when full cassandra type class names are given
Key: CASSANDRA-4546
URL: https://issues.apache.org/jira/browse/CASSANDRA-4546
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.2
Reporter: paul cannon
Assignee: paul cannon
Labels: cqlsh
Fix For: 1.2
Attachments: 4546.patch.txt
When a builtin Cassandra type was being used for data in previous versions of
Cassandra, only the short name was sent: UTF8Type, TimeUUIDType, etc.
Starting with 1.2, as of CASSANDRA-4453, the full class names are sent.
Cqlsh doesn't know how to handle this, and is currently treating all data as
if it were an unknown type. This goes as far as to cause an exception when
the type is actually a number, because the driver deserializes it right, and
then cqlsh tries to use it as a string.
Here for googlage:
{noformat}
AttributeError: 'int' object has no attribute 'replace'
{noformat}
Fixeries are in order.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4485) cqlsh: support collections
[ https://issues.apache.org/jira/browse/CASSANDRA-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13433382#comment-13433382 ] paul cannon commented on CASSANDRA-4485: (CASSANDRA-4500) cqlsh: support collections -- Key: CASSANDRA-4485 URL: https://issues.apache.org/jira/browse/CASSANDRA-4485 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: paul cannon Priority: Minor Fix For: 1.2 Attachments: 4485-super-basic.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4498) Remove openjdk-6-jre Cassandra APT dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13433617#comment-13433617 ] paul cannon commented on CASSANDRA-4498: bq. We could even resurrect one of the more specific java package builders that were popular before Sun grew a pair, and Oracle cut them off. Wouldn't that expose the project to the same legal problems? bq. Finally, if integration with Linux distributions is important, we should be focusing our efforts on OpenJDK, since the Oracle version is always going to be a pain. I realize that may not be the easiest path, but that's often the case for the right/correct one. Definitely moving toward full OpenJDK 7 support is the right thing to do, but it's probably somewhat long-term and out of scope for this ticket. Spending effort on OpenJDK 6 seems like kind of a waste. Remove openjdk-6-jre Cassandra APT dependencies --- Key: CASSANDRA-4498 URL: https://issues.apache.org/jira/browse/CASSANDRA-4498 Project: Cassandra Issue Type: Improvement Reporter: Terrance Shepherd Assignee: paul cannon Priority: Minor Labels: debian Fix For: 1.1.4, 1.2 Attachments: apache_cassandra_Packages.diff As it is well known the recommended jre for Cassandra is sun java 1.6 but at this point that package no longer in the debian or ubuntu apt repos. In order to run Cassandra with the sun java 1.6 jre it must be installed manually with out the repos. Because of this when you install cassandra via the apache or datastax apt repos it must also install openjdk-6-jre even though sun java 1.6 jre is already installed. I would suggest that the java apt dependencies be removed from the Depends field in package configuration and move to either the Recommends or Suggests field so that way openjdk is not being downloaded when not necessary and possibly interfering with a be pre-installed jre -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4498) Remove openjdk-6-jre Cassandra APT dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13433678#comment-13433678 ] paul cannon commented on CASSANDRA-4498: bq. What is it that currently stops OpenJDK 7 from being a good choice. I haven't done any thorough testing, but it seems to work fairly well with Cassandra (but then again, so does OpenJDK 6 for the most part). I've only heard assertions that it's still pretty buggy (such as [here|https://issues.apache.org/jira/browse/CASSANDRA-4275?focusedCommentId=13419886page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13419886]), and that it's had little to no thorough real-world testing. Would definitely be nice to have though. As far as the ticket comment, the submitter says that installing openjdk-6-jre can potentially interfere with a preexisting sun JRE install. Is that just the potential for the new JRE to show up first in $PATH and be preferred by the alternatives system, or is there some more significant problem? Remove openjdk-6-jre Cassandra APT dependencies --- Key: CASSANDRA-4498 URL: https://issues.apache.org/jira/browse/CASSANDRA-4498 Project: Cassandra Issue Type: Improvement Reporter: Terrance Shepherd Assignee: paul cannon Priority: Minor Labels: debian Fix For: 1.1.4, 1.2 Attachments: apache_cassandra_Packages.diff As it is well known the recommended jre for Cassandra is sun java 1.6 but at this point that package no longer in the debian or ubuntu apt repos. In order to run Cassandra with the sun java 1.6 jre it must be installed manually with out the repos. Because of this when you install cassandra via the apache or datastax apt repos it must also install openjdk-6-jre even though sun java 1.6 jre is already installed. I would suggest that the java apt dependencies be removed from the Depends field in package configuration and move to either the Recommends or Suggests field so that way openjdk is not being downloaded when not necessary and possibly interfering with a be pre-installed jre -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4500) cqlsh: understand updated encodings for collections
paul cannon created CASSANDRA-4500: -- Summary: cqlsh: understand updated encodings for collections Key: CASSANDRA-4500 URL: https://issues.apache.org/jira/browse/CASSANDRA-4500 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.2 Reporter: paul cannon Assignee: paul cannon Fix For: 1.2 After CASSANDRA-4453, collections will be represented using the binary encoding in thrift CqlResults instead of json. Update cqlsh (and python-cql as necessary) to support. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4494) nodetool can't work at all !
[
https://issues.apache.org/jira/browse/CASSANDRA-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon updated CASSANDRA-4494:
---
Attachment: 4494-sh-error.patch.txt
Guess POSIX sh doesn't allow omission of curly braces around a function body of
a single command. Dash fails at being a plain posix sh again :(
nodetool can't work at all !
Key: CASSANDRA-4494
URL: https://issues.apache.org/jira/browse/CASSANDRA-4494
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.1.3
Environment: centos 64bit
Reporter: sunjian
Assignee: paul cannon
Priority: Critical
Fix For: 1.1.3
Attachments: 4494-sh-error.patch.txt
1. download cassandra 1.1.3 , then start with {cassandra}/bin/cassandra -pf
2. cd to bin , call nodetool as ./nodetool -h localhost ring
3. console returned : failed to connect to 'localhost:7199' : connection
refused
BUT ,
at the same centos , all was ok before (1.1.2) .
PS:
cassandra-cli/cqlsh works well (1.1.3)
--
update:
even if add the following in cassandra-env.sh , connection refused as well :
JVM_OPTS=$JVM_OPTS -Djava.rmi.server.hostname=10.10.30.11
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4485) cqlsh: support collections
[ https://issues.apache.org/jira/browse/CASSANDRA-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13430698#comment-13430698 ] paul cannon commented on CASSANDRA-4485: That sounds like a good idea to me. The drivers should be able to handle that fine. The change adding the parameters for the collection types in CqlResult will help a lot here too. I'll open a new ticket for this. cqlsh: support collections -- Key: CASSANDRA-4485 URL: https://issues.apache.org/jira/browse/CASSANDRA-4485 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: paul cannon Priority: Minor Fix For: 1.2 Attachments: 4485-super-basic.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4491) cqlsh needs to use system.local instead of system.Versions
paul cannon created CASSANDRA-4491: -- Summary: cqlsh needs to use system.local instead of system.Versions Key: CASSANDRA-4491 URL: https://issues.apache.org/jira/browse/CASSANDRA-4491 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.2 Reporter: paul cannon Assignee: paul cannon Priority: Minor Fix For: 1.2 Apparently the system.Versions table was removed as part of CASSANDRA-4018. cqlsh in 1.2 should use system.local preferentially, and fall back on system.Versions to keep backwards compatibility with older c*. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4491) cqlsh needs to use system.local instead of system.Versions
[ https://issues.apache.org/jira/browse/CASSANDRA-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-4491: --- Description: Apparently the system.Versions table was removed as part of CASSANDRA-4018. cqlsh in 1.2 should use system.local preferentially, and fall back on system.Versions to keep backwards compatibility with older c*. Also changed in 4018: all the system.schema_* CFs now use columns named keyspace_name, columnfamily_name, and column_name instead of keyspace, columnfamily, and column. was:Apparently the system.Versions table was removed as part of CASSANDRA-4018. cqlsh in 1.2 should use system.local preferentially, and fall back on system.Versions to keep backwards compatibility with older c*. Labels: cqlsh (was: ) cqlsh needs to use system.local instead of system.Versions -- Key: CASSANDRA-4491 URL: https://issues.apache.org/jira/browse/CASSANDRA-4491 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.2 Reporter: paul cannon Assignee: paul cannon Priority: Minor Labels: cqlsh Fix For: 1.2 Apparently the system.Versions table was removed as part of CASSANDRA-4018. cqlsh in 1.2 should use system.local preferentially, and fall back on system.Versions to keep backwards compatibility with older c*. Also changed in 4018: all the system.schema_* CFs now use columns named keyspace_name, columnfamily_name, and column_name instead of keyspace, columnfamily, and column. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3647) Support collection (list, set, and map) value types in CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-3647: --- Attachment: 3647-nit.txt Just a small thing that would make cqlsh's life a little easier in trying to make sense of the 'comparator' field in system.schema_columnfamilies. The formatting in TypeParser.stringifyCollectionParameters is a bit backwards. Don't think this justifies a reopen. Support collection (list, set, and map) value types in CQL -- Key: CASSANDRA-3647 URL: https://issues.apache.org/jira/browse/CASSANDRA-3647 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Labels: cql Fix For: 1.2 Attachments: 3647-nit.txt, CASSANDRA-3647-alternative.patch Composite columns introduce the ability to have arbitrarily nested data in a Cassandra row. We should expose this through CQL. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4485) cqlsh: support collections
[
https://issues.apache.org/jira/browse/CASSANDRA-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon updated CASSANDRA-4485:
---
Attachment: 4485-super-basic.txt
Attaching very basic support (essentially, just learn how to lex the [] and {}
tokens, so that collections-related queries don't fail). Shows collections
output values as the plain json returned from cassandra, but that will normally
be good enough.
I'm working on much smarter support, but it's ending up needing a lot of
related improvements, like CASSANDRA-4491 and a little adjustment to
CASSANDRA-3647, plus some tab-completion updates. Will take a bit longer to
finish up.
cqlsh: support collections
--
Key: CASSANDRA-4485
URL: https://issues.apache.org/jira/browse/CASSANDRA-4485
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: paul cannon
Priority: Minor
Fix For: 1.2
Attachments: 4485-super-basic.txt
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4486) UnavailableException when setting up a keyspace without a replication factor
[
https://issues.apache.org/jira/browse/CASSANDRA-4486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13428378#comment-13428378
]
paul cannon commented on CASSANDRA-4486:
Why would this set up a zero-replication keyspace? My reading of the code says
that the default config for a bare create keyspace foo in cassandra-cli is
NTS with {datacenter1:1}. And this cluster is supposed to have 4 nodes.
UnavailableException when setting up a keyspace without a replication factor
Key: CASSANDRA-4486
URL: https://issues.apache.org/jira/browse/CASSANDRA-4486
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.10
Environment: ubuntu 12.04
Reporter: Steve Arch
Priority: Minor
We have a cassandra cluster of 4 nodes. When I use cassandra cli to set up a
keyspace without explicitely setting a replication factor, trying to add a CF
fails with an UnavailableException:
[default@unknown] create keyspace foo;
ae639ba0-d4b8-11e1--424d3d43a8df
Waiting for schema agreement...
schemas agree across the cluster
[default@unknown] use foo;
Authenticated to keyspace: foo
[default@foo] create column family User with comparator = UTF8Type;
b4608180-d4b8-11e1--424d3d43a8df
Waiting for schema agreement...
schemas agree across the cluster
[default@foo] update column family User with
... column_metadata =
... [
... {column_name: first, validation_class: UTF8Type},
... {column_name: last, validation_class: UTF8Type},
... {column_name: age, validation_class: UTF8Type, index_type:
KEYS}
... ];
b70562c0-d4b8-11e1--424d3d43a8df
Waiting for schema agreement...
schemas agree across the cluster
[default@foo] set User['jsmith']['first'] = 'John';
null
UnavailableException()
at
org.apache.cassandra.thrift.Cassandra$insert_result.read(Cassandra.java:15206)
at
org.apache.cassandra.thrift.Cassandra$Client.recv_insert(Cassandra.java:858)
at
org.apache.cassandra.thrift.Cassandra$Client.insert(Cassandra.java:830)
at org.apache.cassandra.cli.CliClient.executeSet(CliClient.java:901)
at
org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:218)
at
org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:220)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:348)
Either this should work fine (and no unavailableException shoud be thrown) or
an exception should be thrown when I create the keyspace because I have set
it up wrong.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4488) update cqlsh recognized syntax (for tab completion, etc)
paul cannon created CASSANDRA-4488: -- Summary: update cqlsh recognized syntax (for tab completion, etc) Key: CASSANDRA-4488 URL: https://issues.apache.org/jira/browse/CASSANDRA-4488 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: paul cannon Assignee: paul cannon Priority: Minor Fix For: 1.1.4, 1.2 cqlsh syntax awareness (tab completion, etc) should be aware of several recent changes to CQL: * CASSANDRA-4179 (row key and column value composites; 1.2 only) * CASSANDRA-3647 (sets/lists/maps; 1.2 only) * CASSANDRA-4018 (inet type; 1.2 only) * CASSANDRA-4278 (hyphens in keyspace properties; 1.1 and up) * CASSANDRA-4217 (accessing ttl, timestamp; 1.1 and up) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4473) Binary protocol: handle asynchronous execution (better)
[ https://issues.apache.org/jira/browse/CASSANDRA-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13426798#comment-13426798 ] paul cannon commented on CASSANDRA-4473: +1. Binary protocol: handle asynchronous execution (better) Key: CASSANDRA-4473 URL: https://issues.apache.org/jira/browse/CASSANDRA-4473 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2 Attachments: 4473-2.txt, 4473.txt The current implementation of the binary protocol handle message asynchronously. I.e. if a client send multiple requests simultaneously, we will handle all request in parallel and in particular we make no guarantee on the order with which the response are sent. But then the client has no way to associate which response correspond to which query. This ticket proposes adding a stream id to each frame. This id would be set to by the client, and the server would just reuse the same id in the response. That way, the client can send multiple simultaneous queries with different stream id and know which response correspond to which request. This has the advantages of 1) being trivial to implement and 2) leaving the possibility for synchronous clients (that wait for responses before sending a new request) to ignore that stream id and just use 0 all the time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4473) Binary protocol: handle asynchronous execution (better)
[ https://issues.apache.org/jira/browse/CASSANDRA-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13426324#comment-13426324 ] paul cannon commented on CASSANDRA-4473: This patch doesn't associate response streamIds with the corresponding request streamIds. Is that an oversight, or is that planned for a future change? Currently all response streamIds from the server will be 0. And just a minor nit: section 2.4 of the native_protocol.spec still describes 'opcode' as being 2 bytes, and gives the possible opcode values as 16-bit hex. Binary protocol: handle asynchronous execution (better) Key: CASSANDRA-4473 URL: https://issues.apache.org/jira/browse/CASSANDRA-4473 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2 Attachments: 4473.txt The current implementation of the binary protocol handle message asynchronously. I.e. if a client send multiple requests simultaneously, we will handle all request in parallel and in particular we make no guarantee on the order with which the response are sent. But then the client has no way to associate which response correspond to which query. This ticket proposes adding a stream id to each frame. This id would be set to by the client, and the server would just reuse the same id in the response. That way, the client can send multiple simultaneous queries with different stream id and know which response correspond to which request. This has the advantages of 1) being trivial to implement and 2) leaving the possibility for synchronous clients (that wait for responses before sending a new request) to ignore that stream id and just use 0 all the time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4447) enable jamm for OpenJDK = 1.6.0.23
[
https://issues.apache.org/jira/browse/CASSANDRA-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon updated CASSANDRA-4447:
---
Attachment: 4447-3.txt
v3 rewritten to be lots more explicit and save the vendor, arch, and version
numbers for later code to use.
enable jamm for OpenJDK = 1.6.0.23
---
Key: CASSANDRA-4447
URL: https://issues.apache.org/jira/browse/CASSANDRA-4447
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Environment: openjdk
Reporter: Ilya Shipitsin
Assignee: Brandon Williams
Priority: Trivial
Fix For: 1.1.3
Attachments: 4447-2.txt, 4447-3.txt, 4447.txt
we tested jamm with OpenJDK, it works well starting at 1.6.0.23, so I suggest
--- cassandra-env.sh.dist 2012-07-19 12:24:44.938886154 +0600
+++ cassandra-env.sh2012-07-19 12:28:34.913886847 +0600
@@ -119,8 +119,10 @@
# add the jamm javaagent
check_openjdk=`${JAVA:-java} -version 21 | awk '{if (NR == 2) {print
$1}}'`
-if [ $check_openjdk != OpenJDK ]
+check_openjdk_is_good_for_jamm=`${JAVA:-java} -version 21 | awk -F
_|\ '/1\.6\.0/ $3 23 {print bad }'`
+if [ $check_openjdk = OpenJDK ] [ $check_openjdk_is_good_for_jamm =
bad ]
then
+else
JVM_OPTS=$JVM_OPTS -javaagent:$CASSANDRA_HOME/lib/jamm-0.2.5.jar
fi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4447) enable jamm for OpenJDK = 1.6.0.23
[
https://issues.apache.org/jira/browse/CASSANDRA-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon updated CASSANDRA-4447:
---
Attachment: 4447-4.txt
v4 is dash-friendly (not completely sure if it's all the way POSIX-compatible,
cause it looks like dash is no longer sticking to POSIX only?)
enable jamm for OpenJDK = 1.6.0.23
---
Key: CASSANDRA-4447
URL: https://issues.apache.org/jira/browse/CASSANDRA-4447
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Environment: openjdk
Reporter: Ilya Shipitsin
Assignee: paul cannon
Priority: Trivial
Fix For: 1.1.3
Attachments: 4447-4.txt, 4447.txt
we tested jamm with OpenJDK, it works well starting at 1.6.0.23, so I suggest
--- cassandra-env.sh.dist 2012-07-19 12:24:44.938886154 +0600
+++ cassandra-env.sh2012-07-19 12:28:34.913886847 +0600
@@ -119,8 +119,10 @@
# add the jamm javaagent
check_openjdk=`${JAVA:-java} -version 21 | awk '{if (NR == 2) {print
$1}}'`
-if [ $check_openjdk != OpenJDK ]
+check_openjdk_is_good_for_jamm=`${JAVA:-java} -version 21 | awk -F
_|\ '/1\.6\.0/ $3 23 {print bad }'`
+if [ $check_openjdk = OpenJDK ] [ $check_openjdk_is_good_for_jamm =
bad ]
then
+else
JVM_OPTS=$JVM_OPTS -javaagent:$CASSANDRA_HOME/lib/jamm-0.2.5.jar
fi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4447) enable jamm for OpenJDK = 1.6.0.23
[
https://issues.apache.org/jira/browse/CASSANDRA-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon updated CASSANDRA-4447:
---
Attachment: (was: 4447-2.txt)
enable jamm for OpenJDK = 1.6.0.23
---
Key: CASSANDRA-4447
URL: https://issues.apache.org/jira/browse/CASSANDRA-4447
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Environment: openjdk
Reporter: Ilya Shipitsin
Assignee: paul cannon
Priority: Trivial
Fix For: 1.1.3
Attachments: 4447-4.txt, 4447.txt
we tested jamm with OpenJDK, it works well starting at 1.6.0.23, so I suggest
--- cassandra-env.sh.dist 2012-07-19 12:24:44.938886154 +0600
+++ cassandra-env.sh2012-07-19 12:28:34.913886847 +0600
@@ -119,8 +119,10 @@
# add the jamm javaagent
check_openjdk=`${JAVA:-java} -version 21 | awk '{if (NR == 2) {print
$1}}'`
-if [ $check_openjdk != OpenJDK ]
+check_openjdk_is_good_for_jamm=`${JAVA:-java} -version 21 | awk -F
_|\ '/1\.6\.0/ $3 23 {print bad }'`
+if [ $check_openjdk = OpenJDK ] [ $check_openjdk_is_good_for_jamm =
bad ]
then
+else
JVM_OPTS=$JVM_OPTS -javaagent:$CASSANDRA_HOME/lib/jamm-0.2.5.jar
fi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4447) enable jamm for OpenJDK = 1.6.0.23
[
https://issues.apache.org/jira/browse/CASSANDRA-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon updated CASSANDRA-4447:
---
Attachment: (was: 4447-3.txt)
enable jamm for OpenJDK = 1.6.0.23
---
Key: CASSANDRA-4447
URL: https://issues.apache.org/jira/browse/CASSANDRA-4447
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Environment: openjdk
Reporter: Ilya Shipitsin
Assignee: paul cannon
Priority: Trivial
Fix For: 1.1.3
Attachments: 4447-4.txt, 4447.txt
we tested jamm with OpenJDK, it works well starting at 1.6.0.23, so I suggest
--- cassandra-env.sh.dist 2012-07-19 12:24:44.938886154 +0600
+++ cassandra-env.sh2012-07-19 12:28:34.913886847 +0600
@@ -119,8 +119,10 @@
# add the jamm javaagent
check_openjdk=`${JAVA:-java} -version 21 | awk '{if (NR == 2) {print
$1}}'`
-if [ $check_openjdk != OpenJDK ]
+check_openjdk_is_good_for_jamm=`${JAVA:-java} -version 21 | awk -F
_|\ '/1\.6\.0/ $3 23 {print bad }'`
+if [ $check_openjdk = OpenJDK ] [ $check_openjdk_is_good_for_jamm =
bad ]
then
+else
JVM_OPTS=$JVM_OPTS -javaagent:$CASSANDRA_HOME/lib/jamm-0.2.5.jar
fi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4469) Fix online help in cqlsh for COPY commands
paul cannon created CASSANDRA-4469:
--
Summary: Fix online help in cqlsh for COPY commands
Key: CASSANDRA-4469
URL: https://issues.apache.org/jira/browse/CASSANDRA-4469
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.1.2
Reporter: paul cannon
Assignee: paul cannon
Priority: Trivial
Fix For: 1.1.3
Attachments: 4469.txt
the HELP COPY output from cqlsh says:
{noformat}
COPY [cqlsh only]
Imports CSV data into a Cassandra table.
COPY table_name [ ( column [, ...] ) ]
FROM ( 'filename' | STDIN )
[ WITH option='value' [AND ...] ];
COPY table_name [ ( column [, ...] ) ]
TO ( 'filename' | STDOUT )
[ WITH option='value' [AND ...] ];
{noformat}
It's confusing cause COPY is now for both export and import, since
CASSANDRA-4434.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4469) Fix online help in cqlsh for COPY commands
[
https://issues.apache.org/jira/browse/CASSANDRA-4469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon updated CASSANDRA-4469:
---
Attachment: 4469.txt
fix the docstring/help text for COPY
Fix online help in cqlsh for COPY commands
--
Key: CASSANDRA-4469
URL: https://issues.apache.org/jira/browse/CASSANDRA-4469
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.1.2
Reporter: paul cannon
Assignee: paul cannon
Priority: Trivial
Labels: cqlsh
Fix For: 1.1.3
Attachments: 4469.txt
the HELP COPY output from cqlsh says:
{noformat}
COPY [cqlsh only]
Imports CSV data into a Cassandra table.
COPY table_name [ ( column [, ...] ) ]
FROM ( 'filename' | STDIN )
[ WITH option='value' [AND ...] ];
COPY table_name [ ( column [, ...] ) ]
TO ( 'filename' | STDOUT )
[ WITH option='value' [AND ...] ];
{noformat}
It's confusing cause COPY is now for both export and import, since
CASSANDRA-4434.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4470) cqlsh COPY FROM without explicit column names is broken
paul cannon created CASSANDRA-4470:
--
Summary: cqlsh COPY FROM without explicit column names is broken
Key: CASSANDRA-4470
URL: https://issues.apache.org/jira/browse/CASSANDRA-4470
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.1.2
Reporter: paul cannon
Assignee: paul cannon
Fix For: 1.1.3
When trying to do a COPY FROM command in cqlsh without an explicit list of
column names, an error results:
{noformat}
cqlsh:a copy blah from stdin;
[Use \. on a line by itself to end input]
[copy] a,b,c
object of type 'NoneType' has no len()
{noformat}
Broken by the fix for CASSANDRA-4434.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4470) cqlsh COPY FROM without explicit column names is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon updated CASSANDRA-4470:
---
Attachment: 4470.txt
Fixed in attached patch, and in my github, in the 4470 branch. Current version
tagged pending/4470:
https://github.com/thepaul/cassandra/tree/4470
cqlsh COPY FROM without explicit column names is broken
---
Key: CASSANDRA-4470
URL: https://issues.apache.org/jira/browse/CASSANDRA-4470
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.1.2
Reporter: paul cannon
Assignee: paul cannon
Labels: cqlsh
Fix For: 1.1.3
Attachments: 4470.txt
When trying to do a COPY FROM command in cqlsh without an explicit list of
column names, an error results:
{noformat}
cqlsh:a copy blah from stdin;
[Use \. on a line by itself to end input]
[copy] a,b,c
object of type 'NoneType' has no len()
{noformat}
Broken by the fix for CASSANDRA-4434.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4447) enable jamm for OpenJDK = 1.6.0.23
[
https://issues.apache.org/jira/browse/CASSANDRA-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon updated CASSANDRA-4447:
---
Attachment: 4447-2.txt
I was going to recommend something like this instead, since at least on a few
of my machines, java -version is pretty slow, and this would be cleaner.
enable jamm for OpenJDK = 1.6.0.23
---
Key: CASSANDRA-4447
URL: https://issues.apache.org/jira/browse/CASSANDRA-4447
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Environment: openjdk
Reporter: Ilya Shipitsin
Assignee: Brandon Williams
Priority: Trivial
Fix For: 1.1.3
Attachments: 4447-2.txt, 4447.txt
we tested jamm with OpenJDK, it works well starting at 1.6.0.23, so I suggest
--- cassandra-env.sh.dist 2012-07-19 12:24:44.938886154 +0600
+++ cassandra-env.sh2012-07-19 12:28:34.913886847 +0600
@@ -119,8 +119,10 @@
# add the jamm javaagent
check_openjdk=`${JAVA:-java} -version 21 | awk '{if (NR == 2) {print
$1}}'`
-if [ $check_openjdk != OpenJDK ]
+check_openjdk_is_good_for_jamm=`${JAVA:-java} -version 21 | awk -F
_|\ '/1\.6\.0/ $3 23 {print bad }'`
+if [ $check_openjdk = OpenJDK ] [ $check_openjdk_is_good_for_jamm =
bad ]
then
+else
JVM_OPTS=$JVM_OPTS -javaagent:$CASSANDRA_HOME/lib/jamm-0.2.5.jar
fi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4434) add COPY TO
[ https://issues.apache.org/jira/browse/CASSANDRA-4434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-4434: --- Attachment: 0002-cqlsh-COPY-TO-fix-output-file-closing.patch Gah, dumb, I only tested with STDOUT. Fixed that. Extra one-line patch attached, 4434 branch updated, new tag pending/4434-2. add COPY TO --- Key: CASSANDRA-4434 URL: https://issues.apache.org/jira/browse/CASSANDRA-4434 Project: Cassandra Issue Type: New Feature Reporter: Jonathan Ellis Assignee: paul cannon Labels: cqlsh Fix For: 1.1.3 Attachments: 0001-cqlsh-implement-COPY-TO.patch, 0002-cqlsh-COPY-TO-fix-output-file-closing.patch CASSANDRA-4012 added COPY FROM; this is a ticket to add the inverse. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4036) cqlsh: EOF during multiline statement
[ https://issues.apache.org/jira/browse/CASSANDRA-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13421162#comment-13421162 ] paul cannon commented on CASSANDRA-4036: Can't reproduce. Possibly fixed by something else since March? Can you retry, Tyler? cqlsh: EOF during multiline statement - Key: CASSANDRA-4036 URL: https://issues.apache.org/jira/browse/CASSANDRA-4036 Project: Cassandra Issue Type: Bug Reporter: Tyler Patterson Assignee: paul cannon Priority: Trivial Labels: cql, cqlsh press CTRL-d while at the beginning of a line in a multi-line statement. It should exit cqlsh or the multiline statement, but instead it only prints another.... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
