[jira] [Commented] (CASSANDRA-5576) CREATE/DROP TRIGGER in CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680227#comment-13680227
]
Vijay commented on CASSANDRA-5576:
--
It took longer than expected to troubleshoot CFMetaData,
https://github.com/Vijay2win/cassandra/commits/5576-v2 has the following
semantics...
{code}
cqlsh> create TRIGGER test2 ON "Keyspace1"."Standard1" using
'org.apache.cassandra.triggers.InvertedIndex';
cqlsh> SELECT * FROM system.schema_triggers WHERE keyspace_name='Keyspace1' AND
column_family='Standard1';
keyspace_name | column_family | trigger_classes
---+---+--
Keyspace1 | Standard1 | {test2:
org.apache.cassandra.triggers.InvertedIndex}
cqlsh> drop trigger test2 on "Keyspace1"."Standard1";
{code}
The trigger data is now stored in schema_triggers and cli is as follows
{code}
update column family Standard1 with triggers=
'{"test":"org.apache.cassandra.triggers.InvertedIndex"}';
{code}
> CREATE/DROP TRIGGER in CQL
> --
>
> Key: CASSANDRA-5576
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5576
> Project: Cassandra
> Issue Type: Bug
> Components: API, Core
>Reporter: Jonathan Ellis
>Assignee: Vijay
> Fix For: 2.0
>
>
--
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
[2/2] git commit: Merge branch 'cassandra-1.2' into trunk
Merge branch 'cassandra-1.2' into trunk Conflicts: CHANGES.txt src/java/org/apache/cassandra/cql3/Constants.java Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/84d1aaae Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/84d1aaae Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/84d1aaae Branch: refs/heads/trunk Commit: 84d1aaaea7344b1cfe125b431e48224dc20e4447 Parents: 68fa88d 01d4f07 Author: Aleksey Yeschenko Authored: Tue Jun 11 01:12:02 2013 +0300 Committer: Aleksey Yeschenko Committed: Tue Jun 11 01:12:02 2013 +0300 -- CHANGES.txt | 2 ++ src/java/org/apache/cassandra/cql3/Constants.java | 9 +++-- 2 files changed, 5 insertions(+), 6 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/84d1aaae/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/84d1aaae/src/java/org/apache/cassandra/cql3/Constants.java -- diff --cc src/java/org/apache/cassandra/cql3/Constants.java index 3cdcb46,4c9d856..0580413 --- a/src/java/org/apache/cassandra/cql3/Constants.java +++ b/src/java/org/apache/cassandra/cql3/Constants.java @@@ -24,12 -24,8 +24,7 @@@ import org.slf4j.Logger import org.slf4j.LoggerFactory; import org.apache.cassandra.db.ColumnFamily; - import org.apache.cassandra.db.marshal.AbstractType; - import org.apache.cassandra.db.marshal.BytesType; - import org.apache.cassandra.db.marshal.CollectionType; - import org.apache.cassandra.db.marshal.CounterColumnType; - import org.apache.cassandra.db.marshal.LongType; - import org.apache.cassandra.db.marshal.MarshalException; -import org.apache.cassandra.db.filter.QueryPath; + import org.apache.cassandra.db.marshal.*; import org.apache.cassandra.exceptions.InvalidRequestException; import org.apache.cassandra.utils.ByteBufferUtil;
[1/2] git commit: Correct blob literal + ReversedType parsing
Updated Branches:
refs/heads/trunk 68fa88d1e -> 84d1aaaea
Correct blob literal + ReversedType parsing
patch by Aleksey Yeschenko; reviewed by Sylvain Lebresne for
CASSANDRA-5629
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/01d4f07d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/01d4f07d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/01d4f07d
Branch: refs/heads/trunk
Commit: 01d4f07dac3ac9ae4af2638391c5191f5166502b
Parents: ac19be9
Author: Aleksey Yeschenko
Authored: Tue Jun 11 01:08:48 2013 +0300
Committer: Aleksey Yeschenko
Committed: Tue Jun 11 01:08:48 2013 +0300
--
CHANGES.txt | 1 +
src/java/org/apache/cassandra/cql3/Constants.java | 9 +++--
2 files changed, 4 insertions(+), 6 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/01d4f07d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 36493d6..a063d69 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -21,6 +21,7 @@
* Allow creating CUSTOM indexes on collections (CASSANDRA-5615)
* Evaluate now() function at execution time (CASSANDRA-5616)
* Expose detailed read repair metrics (CASSANDRA-5618)
+ * Correct blob literal + ReversedType parsing (CASSANDRA-5629)
Merged from 1.1:
* Remove buggy thrift max message length option (CASSANDRA-5529)
* Fix NPE in Pig's widerow mode (CASSANDRA-5488)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/01d4f07d/src/java/org/apache/cassandra/cql3/Constants.java
--
diff --git a/src/java/org/apache/cassandra/cql3/Constants.java
b/src/java/org/apache/cassandra/cql3/Constants.java
index 096c0a8..4c9d856 100644
--- a/src/java/org/apache/cassandra/cql3/Constants.java
+++ b/src/java/org/apache/cassandra/cql3/Constants.java
@@ -25,12 +25,7 @@ import org.slf4j.LoggerFactory;
import org.apache.cassandra.db.ColumnFamily;
import org.apache.cassandra.db.filter.QueryPath;
-import org.apache.cassandra.db.marshal.AbstractType;
-import org.apache.cassandra.db.marshal.BytesType;
-import org.apache.cassandra.db.marshal.CollectionType;
-import org.apache.cassandra.db.marshal.CounterColumnType;
-import org.apache.cassandra.db.marshal.LongType;
-import org.apache.cassandra.db.marshal.MarshalException;
+import org.apache.cassandra.db.marshal.*;
import org.apache.cassandra.exceptions.InvalidRequestException;
import org.apache.cassandra.utils.ByteBufferUtil;
@@ -133,6 +128,8 @@ public abstract class Constants
private ByteBuffer parsedValue(AbstractType validator) throws
InvalidRequestException
{
+if (validator instanceof ReversedType)
+validator = ((ReversedType) validator).baseType;
try
{
// BytesType doesn't want it's input prefixed by '0x'.
git commit: Correct blob literal + ReversedType parsing
Updated Branches:
refs/heads/cassandra-1.2 ac19be985 -> 01d4f07da
Correct blob literal + ReversedType parsing
patch by Aleksey Yeschenko; reviewed by Sylvain Lebresne for
CASSANDRA-5629
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/01d4f07d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/01d4f07d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/01d4f07d
Branch: refs/heads/cassandra-1.2
Commit: 01d4f07dac3ac9ae4af2638391c5191f5166502b
Parents: ac19be9
Author: Aleksey Yeschenko
Authored: Tue Jun 11 01:08:48 2013 +0300
Committer: Aleksey Yeschenko
Committed: Tue Jun 11 01:08:48 2013 +0300
--
CHANGES.txt | 1 +
src/java/org/apache/cassandra/cql3/Constants.java | 9 +++--
2 files changed, 4 insertions(+), 6 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/01d4f07d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 36493d6..a063d69 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -21,6 +21,7 @@
* Allow creating CUSTOM indexes on collections (CASSANDRA-5615)
* Evaluate now() function at execution time (CASSANDRA-5616)
* Expose detailed read repair metrics (CASSANDRA-5618)
+ * Correct blob literal + ReversedType parsing (CASSANDRA-5629)
Merged from 1.1:
* Remove buggy thrift max message length option (CASSANDRA-5529)
* Fix NPE in Pig's widerow mode (CASSANDRA-5488)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/01d4f07d/src/java/org/apache/cassandra/cql3/Constants.java
--
diff --git a/src/java/org/apache/cassandra/cql3/Constants.java
b/src/java/org/apache/cassandra/cql3/Constants.java
index 096c0a8..4c9d856 100644
--- a/src/java/org/apache/cassandra/cql3/Constants.java
+++ b/src/java/org/apache/cassandra/cql3/Constants.java
@@ -25,12 +25,7 @@ import org.slf4j.LoggerFactory;
import org.apache.cassandra.db.ColumnFamily;
import org.apache.cassandra.db.filter.QueryPath;
-import org.apache.cassandra.db.marshal.AbstractType;
-import org.apache.cassandra.db.marshal.BytesType;
-import org.apache.cassandra.db.marshal.CollectionType;
-import org.apache.cassandra.db.marshal.CounterColumnType;
-import org.apache.cassandra.db.marshal.LongType;
-import org.apache.cassandra.db.marshal.MarshalException;
+import org.apache.cassandra.db.marshal.*;
import org.apache.cassandra.exceptions.InvalidRequestException;
import org.apache.cassandra.utils.ByteBufferUtil;
@@ -133,6 +128,8 @@ public abstract class Constants
private ByteBuffer parsedValue(AbstractType validator) throws
InvalidRequestException
{
+if (validator instanceof ReversedType)
+validator = ((ReversedType) validator).baseType;
try
{
// BytesType doesn't want it's input prefixed by '0x'.
[jira] [Commented] (CASSANDRA-5629) Incorrect handling of blob literals when the blob column is in reverse clustering order
[ https://issues.apache.org/jira/browse/CASSANDRA-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679970#comment-13679970 ] Sylvain Lebresne commented on CASSANDRA-5629: - +1 > Incorrect handling of blob literals when the blob column is in reverse > clustering order > --- > > Key: CASSANDRA-5629 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5629 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.2.5 >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko > Labels: cql3 > Fix For: 1.2.6 > > Attachments: 5629.txt > > > Parsing goes through ReversedType.fromString() in this case, and that doesn't > strip "0x" when calling BytesType.fromString(). > The attached patch makes Constants.parsedValue() ReversedType-aware. -- 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-5629) Incorrect handling of blob literals when the blob column is in reverse clustering order
Aleksey Yeschenko created CASSANDRA-5629: Summary: Incorrect handling of blob literals when the blob column is in reverse clustering order Key: CASSANDRA-5629 URL: https://issues.apache.org/jira/browse/CASSANDRA-5629 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5 Reporter: Aleksey Yeschenko Assignee: Aleksey Yeschenko Fix For: 1.2.6 Attachments: 5629.txt Parsing goes through ReversedType.fromString() in this case, and that doesn't strip "0x" when calling BytesType.fromString(). The attached patch makes Constants.parsedValue() ReversedType-aware. -- 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-5629) Incorrect handling of blob literals when the blob column is in reverse clustering order
[ https://issues.apache.org/jira/browse/CASSANDRA-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-5629: - Attachment: 5629.txt > Incorrect handling of blob literals when the blob column is in reverse > clustering order > --- > > Key: CASSANDRA-5629 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5629 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.2.5 >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko > Labels: cql3 > Fix For: 1.2.6 > > Attachments: 5629.txt > > > Parsing goes through ReversedType.fromString() in this case, and that doesn't > strip "0x" when calling BytesType.fromString(). > The attached patch makes Constants.parsedValue() ReversedType-aware. -- 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-5623) Cleanup interruption handling
[ https://issues.apache.org/jira/browse/CASSANDRA-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679900#comment-13679900 ] Dave Brosius commented on CASSANDRA-5623: - This changes the semantics of what was going on. I can see using Futures.getUnchecked etc, to clean the code up some. I'm not sure I understand the intention of this patch, as it makes this non interruptable, which is completely different, and to me seems wrong. But perhaps it went over my head. > Cleanup interruption handling > - > > Key: CASSANDRA-5623 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5623 > Project: Cassandra > Issue Type: Improvement >Reporter: Mikhail Mazursky >Assignee: Mikhail Mazursky >Priority: Minor > Fix For: 2.0 > > Attachments: trunk-5623.txt > > > There are a lot of catch-wrap-throw pattern occurances in code with > InterruptedException. I cleaned up some of them but not all - in some places > I don't know enough about code to decide if it's correct thing to do. > Important: I also fixed possibility of wrong behaviour in case of spurious > wakeup in AsyncOneResponse. -- 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-5555) Allow sstableloader to handle a larger number of files
[ https://issues.apache.org/jira/browse/CASSANDRA-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679863#comment-13679863 ] Mike Bulman commented on CASSANDRA-: bq. We already committed a fix for 1.2.6. Yeah. Alex is just helping to QA this, so those are the steps to reproduce pre-1.2.6, and then we'll run them again on 1.2.6+ > Allow sstableloader to handle a larger number of files > -- > > Key: CASSANDRA- > URL: https://issues.apache.org/jira/browse/CASSANDRA- > Project: Cassandra > Issue Type: Improvement > Components: Core, Tools >Reporter: Tyler Hobbs >Assignee: Jonathan Ellis > Fix For: 1.2.6 > > Attachments: -01.txt, -02.txt, CASSANDRA-.txt, > CASSANDRA-.txt > > > With the default heap size, sstableloader will OOM when there are roughly 25k > files in the directory to load. It's easy to reach this number of files in a > single LCS column family. > By avoiding creating all SSTableReaders up front in SSTableLoader, we should > be able to increase the number of files that sstableloader can handle > considerably. -- 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-5555) Allow sstableloader to handle a larger number of files
[ https://issues.apache.org/jira/browse/CASSANDRA-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Zarutin updated CASSANDRA-: Attachment: CASSANDRA-.txt Updated repro steps. Reviewed by Mike Bulman > Allow sstableloader to handle a larger number of files > -- > > Key: CASSANDRA- > URL: https://issues.apache.org/jira/browse/CASSANDRA- > Project: Cassandra > Issue Type: Improvement > Components: Core, Tools >Reporter: Tyler Hobbs >Assignee: Jonathan Ellis > Fix For: 1.2.6 > > Attachments: -01.txt, -02.txt, CASSANDRA-.txt, > CASSANDRA-.txt > > > With the default heap size, sstableloader will OOM when there are roughly 25k > files in the directory to load. It's easy to reach this number of files in a > single LCS column family. > By avoiding creating all SSTableReaders up front in SSTableLoader, we should > be able to increase the number of files that sstableloader can handle > considerably. -- 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-5555) Allow sstableloader to handle a larger number of files
[ https://issues.apache.org/jira/browse/CASSANDRA-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679832#comment-13679832 ] Jonathan Ellis commented on CASSANDRA-: --- We already committed a fix for 1.2.6. > Allow sstableloader to handle a larger number of files > -- > > Key: CASSANDRA- > URL: https://issues.apache.org/jira/browse/CASSANDRA- > Project: Cassandra > Issue Type: Improvement > Components: Core, Tools >Reporter: Tyler Hobbs >Assignee: Jonathan Ellis > Fix For: 1.2.6 > > Attachments: -01.txt, -02.txt, CASSANDRA-.txt > > > With the default heap size, sstableloader will OOM when there are roughly 25k > files in the directory to load. It's easy to reach this number of files in a > single LCS column family. > By avoiding creating all SSTableReaders up front in SSTableLoader, we should > be able to increase the number of files that sstableloader can handle > considerably. -- 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-5555) Allow sstableloader to handle a larger number of files
[ https://issues.apache.org/jira/browse/CASSANDRA-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Zarutin updated CASSANDRA-: Attachment: CASSANDRA-.txt Repro steps > Allow sstableloader to handle a larger number of files > -- > > Key: CASSANDRA- > URL: https://issues.apache.org/jira/browse/CASSANDRA- > Project: Cassandra > Issue Type: Improvement > Components: Core, Tools >Reporter: Tyler Hobbs >Assignee: Jonathan Ellis > Fix For: 1.2.6 > > Attachments: -01.txt, -02.txt, CASSANDRA-.txt > > > With the default heap size, sstableloader will OOM when there are roughly 25k > files in the directory to load. It's easy to reach this number of files in a > single LCS column family. > By avoiding creating all SSTableReaders up front in SSTableLoader, we should > be able to increase the number of files that sstableloader can handle > considerably. -- 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-5555) Allow sstableloader to handle a larger number of files
[ https://issues.apache.org/jira/browse/CASSANDRA-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679803#comment-13679803 ] Alex Zarutin commented on CASSANDRA-: - Added repro steps based on Cassandra 1.1.9 > Allow sstableloader to handle a larger number of files > -- > > Key: CASSANDRA- > URL: https://issues.apache.org/jira/browse/CASSANDRA- > Project: Cassandra > Issue Type: Improvement > Components: Core, Tools >Reporter: Tyler Hobbs >Assignee: Jonathan Ellis > Fix For: 1.2.6 > > Attachments: -01.txt, -02.txt, CASSANDRA-.txt > > > With the default heap size, sstableloader will OOM when there are roughly 25k > files in the directory to load. It's easy to reach this number of files in a > single LCS column family. > By avoiding creating all SSTableReaders up front in SSTableLoader, we should > be able to increase the number of files that sstableloader can handle > considerably. -- 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-3486) Node Tool command to stop repair
[ https://issues.apache.org/jira/browse/CASSANDRA-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679651#comment-13679651 ] Bill Hathaway commented on CASSANDRA-3486: -- I hit this today on 1.1.10. node X was running a repair that was hung. It had several SS tables it reported it was streaming from node Y. Node Y reported it was not streaming anything to node X. It looks like our only solution is to bounce the node, which is frustrating. A 'nodetool stop repair' would have been very helpful in my scenario. > Node Tool command to stop repair > > > Key: CASSANDRA-3486 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3486 > Project: Cassandra > Issue Type: Improvement > Components: Tools > Environment: JVM >Reporter: Vijay >Priority: Minor > Labels: repair > Fix For: 2.1 > > Attachments: 0001-stop-repair-3583.patch > > > After CASSANDRA-1740, If the validation compaction is stopped then the repair > will hang. This ticket will allow users to kill the original repair. -- 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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679642#comment-13679642 ] Sylvain Lebresne commented on CASSANDRA-5149: - I still don't see where the problem is. Can you illustrate with a concrete example what is the problem we can run into if we just have Expiring.create() that doesn't transform in the case of the row cache but do transform based on the "read request timestamp" in all other cases? > Respect slice count even if column expire mid-request > - > > Key: CASSANDRA-5149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 > Project: Cassandra > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Sylvain Lebresne >Assignee: Aleksey Yeschenko > Fix For: 2.0 > > > This is a follow-up of CASSANDRA-5099. > If a column expire just while a slice query is performed, it is possible for > replicas to count said column as live but to have the coordinator seeing it > as dead when building the final result. The effect that the query might > return strictly less columns that the requested slice count even though there > is some live columns matching the slice predicate but not returned in the > result. -- 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-5628) cqlsh "copy to" fails when there are more than 21 columns
[
https://issues.apache.org/jira/browse/CASSANDRA-5628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679612#comment-13679612
]
Jonathan Ellis commented on CASSANDRA-5628:
---
Does this affect 1.2 as well?
> cqlsh "copy to" fails when there are more than 21 columns
> -
>
> Key: CASSANDRA-5628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5628
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.1.12
> Environment: ubuntu 13.04
> $ uname -a
> Linux ian 3.8.0-23-generic #34-Ubuntu SMP Wed May 29 20:22:58 UTC 2013 x86_64
> x86_64 x86_64 GNU/Linux
> $ cqlsh --version
> cqlsh 2.2.0
> $ nodetool -h localhost version
> ReleaseVersion: 1.1.12
> $ dpkg -l python-cql
> 1.4.0-1 DB-API 2.0 compliant client library for Cassandra/CQL
>Reporter: Ian Rogers
>
> See the cqlsh script below. If you comment out the "c1" line then the "copy
> to" command exports 0 rows even though the "select *" works fine!
> USE test_keyspace;
> DROP TABLE foo;
> CREATE TABLE foo (
> id varchar PRIMARY KEY,
> a0 varchar,
> a1 varchar,
> a2 varchar,
> a3 varchar,
> a4 varchar,
> a5 varchar,
> a6 varchar,
> a7 varchar,
> a8 varchar,
> a9 varchar,
> b0 varchar,
> b1 varchar,
> b2 varchar,
> b3 varchar,
> b4 varchar,
> b5 varchar,
> b6 varchar,
> b7 varchar,
> b8 varchar,
> b9 varchar,
> c0 varchar,
> -- c1 varchar, -- uncomment this line and the "copy" will fail even though
> the "select" works fine!
> );
> insert into foo (id, a1) values ('foo', 'grum');
> select * from foo;
> copy foo to '/tmp/foo.csv';
--
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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679598#comment-13679598 ] Aleksey Yeschenko commented on CASSANDRA-5149: -- I wasn't clear enough. I'm talking about read request timestamps, not column timestamps. And I'm saying that to transfrom is not always correct, in the context of 5149. But *not to* transfrom is perfectly all right. > Respect slice count even if column expire mid-request > - > > Key: CASSANDRA-5149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 > Project: Cassandra > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Sylvain Lebresne >Assignee: Aleksey Yeschenko > Fix For: 2.0 > > > This is a follow-up of CASSANDRA-5099. > If a column expire just while a slice query is performed, it is possible for > replicas to count said column as live but to have the coordinator seeing it > as dead when building the final result. The effect that the query might > return strictly less columns that the requested slice count even though there > is some live columns matching the slice predicate but not returned in the > result. -- 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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679581#comment-13679581 ] Sylvain Lebresne commented on CASSANDRA-5149: - bq. But I'm afraid it's not enough I'm not sure I understand the case you are talking about. Whether or not ExpiringColumn.create() decides to return a deleted column or not, it still returns a column, so this should have no impact whatsoever on anything timestamp related. I.e. the code will treat an ExpiringColumn that is expired exactly as a deleted column, so it should always be safe to not transform an expired column to a DeletedColumn, even if it's only in parts of the code. But it could be I just don't understand your example. > Respect slice count even if column expire mid-request > - > > Key: CASSANDRA-5149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 > Project: Cassandra > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Sylvain Lebresne >Assignee: Aleksey Yeschenko > Fix For: 2.0 > > > This is a follow-up of CASSANDRA-5099. > If a column expire just while a slice query is performed, it is possible for > replicas to count said column as live but to have the coordinator seeing it > as dead when building the final result. The effect that the query might > return strictly less columns that the requested slice count even though there > is some live columns matching the slice predicate but not returned in the > result. -- 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-5628) cqlsh "copy to" fails when there are more than 21 columns
[
https://issues.apache.org/jira/browse/CASSANDRA-5628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Rogers updated CASSANDRA-5628:
--
Environment:
ubuntu 13.04
$ uname -a
Linux ian 3.8.0-23-generic #34-Ubuntu SMP Wed May 29 20:22:58 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux
$ cqlsh --version
cqlsh 2.2.0
$ nodetool -h localhost version
ReleaseVersion: 1.1.12
$ dpkg -l python-cql
1.4.0-1 DB-API 2.0 compliant client library for Cassandra/CQL
was:
ubuntu 13.04
$ uname -a
Linux ian 3.8.0-23-generic #34-Ubuntu SMP Wed May 29 20:22:58 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux
$ cqlsh --version
cqlsh 2.2.0
$ nodetool -h localhost version
ReleaseVersion: 1.1.12
> cqlsh "copy to" fails when there are more than 21 columns
> -
>
> Key: CASSANDRA-5628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5628
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.1.12
> Environment: ubuntu 13.04
> $ uname -a
> Linux ian 3.8.0-23-generic #34-Ubuntu SMP Wed May 29 20:22:58 UTC 2013 x86_64
> x86_64 x86_64 GNU/Linux
> $ cqlsh --version
> cqlsh 2.2.0
> $ nodetool -h localhost version
> ReleaseVersion: 1.1.12
> $ dpkg -l python-cql
> 1.4.0-1 DB-API 2.0 compliant client library for Cassandra/CQL
>Reporter: Ian Rogers
>
> See the cqlsh script below. If you comment out the "c1" line then the "copy
> to" command exports 0 rows even though the "select *" works fine!
> USE test_keyspace;
> DROP TABLE foo;
> CREATE TABLE foo (
> id varchar PRIMARY KEY,
> a0 varchar,
> a1 varchar,
> a2 varchar,
> a3 varchar,
> a4 varchar,
> a5 varchar,
> a6 varchar,
> a7 varchar,
> a8 varchar,
> a9 varchar,
> b0 varchar,
> b1 varchar,
> b2 varchar,
> b3 varchar,
> b4 varchar,
> b5 varchar,
> b6 varchar,
> b7 varchar,
> b8 varchar,
> b9 varchar,
> c0 varchar,
> -- c1 varchar, -- uncomment this line and the "copy" will fail even though
> the "select" works fine!
> );
> insert into foo (id, a1) values ('foo', 'grum');
> select * from foo;
> copy foo to '/tmp/foo.csv';
--
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-5628) cqlsh "copy to" fails when there are more than 21 columns
[
https://issues.apache.org/jira/browse/CASSANDRA-5628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Rogers updated CASSANDRA-5628:
--
Summary: cqlsh "copy to" fails when there are more than 21 columns (was:
cqlsh "copy to" fails when there are more than 22 columns)
> cqlsh "copy to" fails when there are more than 21 columns
> -
>
> Key: CASSANDRA-5628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5628
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.1.12
> Environment: ubuntu 13.04
> $ uname -a
> Linux ian 3.8.0-23-generic #34-Ubuntu SMP Wed May 29 20:22:58 UTC 2013 x86_64
> x86_64 x86_64 GNU/Linux
> $ cqlsh --version
> cqlsh 2.2.0
> $ nodetool -h localhost version
> ReleaseVersion: 1.1.12
>Reporter: Ian Rogers
>
> See the cqlsh script below. If you comment out the "c1" line then the "copy
> to" command exports 0 rows even though the "select *" works fine!
> USE test_keyspace;
> DROP TABLE foo;
> CREATE TABLE foo (
> id varchar PRIMARY KEY,
> a0 varchar,
> a1 varchar,
> a2 varchar,
> a3 varchar,
> a4 varchar,
> a5 varchar,
> a6 varchar,
> a7 varchar,
> a8 varchar,
> a9 varchar,
> b0 varchar,
> b1 varchar,
> b2 varchar,
> b3 varchar,
> b4 varchar,
> b5 varchar,
> b6 varchar,
> b7 varchar,
> b8 varchar,
> b9 varchar,
> c0 varchar,
> -- c1 varchar, -- uncomment this line and the "copy" will fail even though
> the "select" works fine!
> );
> insert into foo (id, a1) values ('foo', 'grum');
> select * from foo;
> copy foo to '/tmp/foo.csv';
--
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-5628) cqlsh "copy to" fails when there are more than 22 columns
Ian Rogers created CASSANDRA-5628:
-
Summary: cqlsh "copy to" fails when there are more than 22 columns
Key: CASSANDRA-5628
URL: https://issues.apache.org/jira/browse/CASSANDRA-5628
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.12
Environment: ubuntu 13.04
$ uname -a
Linux ian 3.8.0-23-generic #34-Ubuntu SMP Wed May 29 20:22:58 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux
$ cqlsh --version
cqlsh 2.2.0
$ nodetool -h localhost version
ReleaseVersion: 1.1.12
Reporter: Ian Rogers
See the cqlsh script below. If you comment out the "c1" line then the "copy to"
command exports 0 rows even though the "select *" works fine!
USE test_keyspace;
DROP TABLE foo;
CREATE TABLE foo (
id varchar PRIMARY KEY,
a0 varchar,
a1 varchar,
a2 varchar,
a3 varchar,
a4 varchar,
a5 varchar,
a6 varchar,
a7 varchar,
a8 varchar,
a9 varchar,
b0 varchar,
b1 varchar,
b2 varchar,
b3 varchar,
b4 varchar,
b5 varchar,
b6 varchar,
b7 varchar,
b8 varchar,
b9 varchar,
c0 varchar,
-- c1 varchar, -- uncomment this line and the "copy" will fail even though the
"select" works fine!
);
insert into foo (id, a1) values ('foo', 'grum');
select * from foo;
copy foo to '/tmp/foo.csv';
--
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-5038) LZ4Compressor
[ https://issues.apache.org/jira/browse/CASSANDRA-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679396#comment-13679396 ] Adrien Grand commented on CASSANDRA-5038: - bq. One benefit to LZ4 is that the unsafe implementation isn't much slower than the native version; if we end up going to an incompatible version (or people run on some platform that Snappy/LZ4 native hasn't been created for), they won't have nearly the slowdown that Snappy has (or at least had, not sure if they've addressed that). For your information [~cowtowncoder] ran his JVM compressor benchmark again recently, and indeed, it shows good performance numbers for both the native and the Java impl of LZ4: https://twitter.com/cowtowncoder/status/343881969697951744 > LZ4Compressor > - > > Key: CASSANDRA-5038 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5038 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: T Jake Luciani >Assignee: Adrien Grand >Priority: Minor > Fix For: 1.2.2 > > Attachments: CASSANDRA-5038.patch, CASSANDRA-5038.patch, > CASSANDRA-5038.patch, LZ4Compressor.java, lz4-java.jar > > > LZ4 is a new compression algo that's ~2x faster than Snappy. > [~jpountz] has written a nice java port which includes a misc.Unsafe version > that performs >= than our java snappy version. > Details at http://blog.jpountz.net/post/28092106032/wow-lz4-is-fast > The nice thing is this should work with java7 and be more portable. > We can also fallback the pure java impl -- 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
