[jira] [Issue Comment Edited] (CASSANDRA-3763) compactionstats throws ArithmeticException: / by zero
[ https://issues.apache.org/jira/browse/CASSANDRA-3763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218417#comment-13218417 ] Zenek Kraweznik edited comment on CASSANDRA-3763 at 4/19/12 7:10 AM: - this bug may be linked with CASSANDRA-3693 and CASSANDRA-3731 was (Author: zenek_kraweznik0): this bug may be linked with CASSANDRA-3693 compactionstats throws ArithmeticException: / by zero - Key: CASSANDRA-3763 URL: https://issues.apache.org/jira/browse/CASSANDRA-3763 Project: Cassandra Issue Type: Bug Components: Core, Tools Affects Versions: 1.0.7, 1.0.8, 1.0.9 Environment: debian linux - openvz kernel, oracle java 1.6.0.26 Reporter: Zenek Kraweznik Priority: Trivial compactionstats looks like this: # nodetool -h localhost compactionstats Exception in thread main java.lang.ArithmeticException: / by zero at org.apache.cassandra.db.compaction.LeveledManifest.getEstimatedTasks(LeveledManifest.java:435) at org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getEstimatedRemainingTasks(LeveledCompactionStrategy.java:128) at org.apache.cassandra.db.compaction.CompactionManager.getPendingTasks(CompactionManager.java:1060) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208) at com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:65) at com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:216) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:666) at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:638) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1404) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360) at javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:600) at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) # nodetool is working fine in other actions: # nodetool -h localhost netstats Mode: NORMAL Not sending any streams. Not receiving any streams. Pool NameActive Pending Completed Commandsn/a 0 2 Responses n/a 0 1810 # -- 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-4161) CQL 3.0 does not work in cqlsh with uppercase SELECT
[ https://issues.apache.org/jira/browse/CASSANDRA-4161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257361#comment-13257361 ] Christoph Tavan commented on CASSANDRA-4161: I'm wondering why CQL is being parsed in the client at all? Couldn't we just handle the exceptions thrown by cassandra? That way we wouldn't have to keep cqlsh in sync with CQL development on the C*-side. CQL 3.0 does not work in cqlsh with uppercase SELECT Key: CASSANDRA-4161 URL: https://issues.apache.org/jira/browse/CASSANDRA-4161 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1.0 Environment: cqlsh Reporter: Jonas Dohse Priority: Minor Labels: cql3, cqlsh Attachments: 0001-Allow-CQL-3.0-with-uppercase-SELECT-statement.patch, 4161.patch.txt Uppercase SELECT prevents usage of CQL 3.0 features like ORDER BY Example: select * from test ORDER BY number; # works SELECT * from test ORDER BY number; # fails -- 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-4161) CQL 3.0 does not work in cqlsh with uppercase SELECT
[ https://issues.apache.org/jira/browse/CASSANDRA-4161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257385#comment-13257385 ] Jonas Dohse commented on CASSANDRA-4161: Works for me™ CQL 3.0 does not work in cqlsh with uppercase SELECT Key: CASSANDRA-4161 URL: https://issues.apache.org/jira/browse/CASSANDRA-4161 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1.0 Environment: cqlsh Reporter: Jonas Dohse Priority: Minor Labels: cql3, cqlsh Attachments: 0001-Allow-CQL-3.0-with-uppercase-SELECT-statement.patch, 4161.patch.txt Uppercase SELECT prevents usage of CQL 3.0 features like ORDER BY Example: select * from test ORDER BY number; # works SELECT * from test ORDER BY number; # fails -- 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-3909) Pig should handle wide rows
[ https://issues.apache.org/jira/browse/CASSANDRA-3909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257455#comment-13257455 ] Sylvain Lebresne commented on CASSANDRA-3909: - Is that a big deal if it's only in 1.1.1? I mean, personally I do trust you on that this can't break anything and I don't object on putting it in 1.1.0. I do however think that in general there would be some merit to stick to more strict rules. But that's not a debate related to this issue in particular so let's leave that discussing to some other venue. Pig should handle wide rows --- Key: CASSANDRA-3909 URL: https://issues.apache.org/jira/browse/CASSANDRA-3909 Project: Cassandra Issue Type: Bug Components: Hadoop Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.1.1 Attachments: 3909.txt Pig should be able to use the wide row support in CFIF. -- 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-4004) Add support for ReversedType
[
https://issues.apache.org/jira/browse/CASSANDRA-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257521#comment-13257521
]
Sylvain Lebresne commented on CASSANDRA-4004:
-
bq. From the standpoint of a new user, this is sophistry.
How is that sophistry, seriously? I think it's very important that the
clustered part of th PK induces an ordering of records (which SQL don't have,
but we're not talking about SQL here, right). It's important because you don't
model things the same way in Cassandra than traditionally you do in SQL: you
denormalize, you model time series etc... for which the notion that there is an
ordering or records is not an implementation detail, nor something dealt with
at query time (contrarily to SQL), but is an important part of the model. It
would be confusing for brand new user to *not* say that ordering is part of the
data model (and again yes, that's a difference with SQL). I also don't see how
saying that is in any way related to being a veteran and whatnot. I 200% agree
that CQL3 is an abstraction and that it is A Good Thing. I'm saying the
ordering induced by the PK should be part of that abstraction.
But then it's natural that SELECT without ORDER BY should return records in
that clustering order, which will indeed not be the same than the order of with
ORDER BY ASC *unless* Y is the first clustered key. But if is the first
clustered key, then yes, SELECT and SELECT ORDER BY ASC should be the same (and
they are). But then it's not rocket science to say that if the ordering is
'reversed alphabetical order', then 'z' 'a' and thus a SELECT ORDER BY ASC
returns 'z' before 'a'.
So I absolutely and strongly refute that this proposal is somehow sophistry and
even more so that it's a negation of the abstractive nature of CQL3 or
influenced by the thrift API any more that the solution you're pushing for.
bq. The other relevant context here is that we decided not to support arbitrary
orderings
I'm either misunderstanding what you call 'arbitrary orderings' or I have not
been part of that discussion. Because if you talk of custom types, then CQL3
does support them (you can declare CREATE TABLE foo (k myCustomType PRIMARY
KEY)). And I'm -1 on removing that support, unless someone has compelling
reason to do so because I certainly don't see any and that's useful. And yes, I
do see this as a good reason to go with my proposal, since it's not very
consistent if
{noformat}
CREATE TABLE foo (
k1 uuid,
k2 myEfficientComplexNumberType,
c text,
PRIMARY KEY (k1, k2)
) WITH CLUSTERING ORDER BY (k2 DESC)
{noformat}
is *not* the same than
{noformat}
CREATE TABLE foo (
k1 uuid,
k2 myReversedEfficientComplexNumberType,
c text,
PRIMARY KEY (k1, k2)
)
{noformat}
Add support for ReversedType
Key: CASSANDRA-4004
URL: https://issues.apache.org/jira/browse/CASSANDRA-4004
Project: Cassandra
Issue Type: Sub-task
Components: API
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Trivial
Fix For: 1.1.1
Attachments: 4004.txt
It would be nice to add a native syntax for the use of ReversedType. I'm sure
there is anything in SQL that we inspired ourselves from, so I would propose
something like:
{noformat}
CREATE TABLE timeseries (
key text,
time uuid,
value text,
PRIMARY KEY (key, time DESC)
)
{noformat}
Alternatively, the DESC could also be put after the column name definition
but one argument for putting it in the PK instead is that this only apply to
keys.
--
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-4165) Generate Digest file for compressed SSTables
[ https://issues.apache.org/jira/browse/CASSANDRA-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257534#comment-13257534 ] Sylvain Lebresne commented on CASSANDRA-4165: - We don't really have discussed it more than the reasoning Jonathan explained :). But if it's for external tools, is it still useful to have it computed during the sstable write (i.e, you could generate the sha1 yourself before backupping the file in the first place)? Not that it's much work for us to do it (well, except for the added cpu usage during sstable write maybe). Generate Digest file for compressed SSTables Key: CASSANDRA-4165 URL: https://issues.apache.org/jira/browse/CASSANDRA-4165 Project: Cassandra Issue Type: Improvement Reporter: Marcus Eriksson Priority: Minor Attachments: 0001-Generate-digest-for-compressed-files-as-well.patch We use the generated *Digest.sha1-files to verify backups, would be nice if they were generated for compressed sstables as well. -- 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-4004) Add support for ReversedType
[
https://issues.apache.org/jira/browse/CASSANDRA-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257539#comment-13257539
]
Jonathan Ellis commented on CASSANDRA-4004:
---
bq. I'm either misunderstanding what you call 'arbitrary orderings' or I have
not been part of that discussion
I think you are misunderstanding. This is what I'm referring to:
{code}
. if (stmt.parameters.orderBy != null)
{
CFDefinition.Name name = cfDef.get(stmt.parameters.orderBy);
if (name == null)
throw new InvalidRequestException(String.format(Order by
on unknown column %s, stmt.parameters.orderBy));
if (name.kind != CFDefinition.Name.Kind.COLUMN_ALIAS ||
name.position != 0)
throw new InvalidRequestException(String.format(Order by
is currently only supported on the second column of the PRIMARY KEY (if any),
got %s, stmt.parameters.orderBy));
}
{code}
bq. How is that sophistry, seriously?
ORDER BY X DESC does not mean give me them in the reverse order that Xes are
in on disk, it means give me larger values before smaller ones. This isn't
open for debate, it's a very clear requirement.
Remember that clustering is not new ground for databases; SQL has been there,
done that. As I mentioned when we were designing the CQL3 schema syntax,
RDBMSes have had a concept of clustered indexes for a long, long time. But
clustering on an index ASC or DESC does not affect the results other than as an
optimization; when you ORDER BY X, that's what you get.
SQL and CQL are declarative languages: Here is what I want; you figure out how
to give me the results. This has proved a good design. Modifying the
semantics of a query based on index or clustering or other declarations
elsewhere has ZERO precedent and is bad design to boot; you don't want users to
have to consult their DDL when debugging, to know what results a query will
give.
Thus, the only design that makes sense in the larger context of a declarative
language is to treat the clustering as an optimization as I've described (or
as an index, if you prefer), and continue to reject ORDER BY requests that
are neither forward- nor reverse-clustered.
Add support for ReversedType
Key: CASSANDRA-4004
URL: https://issues.apache.org/jira/browse/CASSANDRA-4004
Project: Cassandra
Issue Type: Sub-task
Components: API
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Trivial
Fix For: 1.1.1
Attachments: 4004.txt
It would be nice to add a native syntax for the use of ReversedType. I'm sure
there is anything in SQL that we inspired ourselves from, so I would propose
something like:
{noformat}
CREATE TABLE timeseries (
key text,
time uuid,
value text,
PRIMARY KEY (key, time DESC)
)
{noformat}
Alternatively, the DESC could also be put after the column name definition
but one argument for putting it in the PK instead is that this only apply to
keys.
--
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-4161) CQL 3.0 does not work in cqlsh with uppercase SELECT
[ https://issues.apache.org/jira/browse/CASSANDRA-4161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257548#comment-13257548 ] paul cannon commented on CASSANDRA-4161: bq. I'm wondering why CQL is being parsed in the client at all? Couldn't we just handle the exceptions thrown by cassandra? That way we wouldn't have to keep cqlsh in sync with CQL development on the C*-side. cqlsh has to attempt to parse input in order to recognize keyspace switches, provide tab-completion, implement the cqlsh-specific commands, separate multiple statements, and (in the future) to allow things like CASSANDRA-3799. Yes, of course, if cqlsh can identify a CQL statement but can't parse it, and it doesn't recognize the command word as being cqlsh-specific, it should pass the CQL on untouched to Cassandra. The problem in this ticket was with cqlsh deciding incorrectly that the user intended to give a cqlsh-only command. CQL 3.0 does not work in cqlsh with uppercase SELECT Key: CASSANDRA-4161 URL: https://issues.apache.org/jira/browse/CASSANDRA-4161 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1.0 Environment: cqlsh Reporter: Jonas Dohse Priority: Minor Labels: cql3, cqlsh Attachments: 0001-Allow-CQL-3.0-with-uppercase-SELECT-statement.patch, 4161.patch.txt Uppercase SELECT prevents usage of CQL 3.0 features like ORDER BY Example: select * from test ORDER BY number; # works SELECT * from test ORDER BY number; # fails -- 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-4161) CQL 3.0 does not work in cqlsh with uppercase SELECT
[ https://issues.apache.org/jira/browse/CASSANDRA-4161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257549#comment-13257549 ] paul cannon commented on CASSANDRA-4161: +1 for 4161.patch.txt. CQL 3.0 does not work in cqlsh with uppercase SELECT Key: CASSANDRA-4161 URL: https://issues.apache.org/jira/browse/CASSANDRA-4161 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1.0 Environment: cqlsh Reporter: Jonas Dohse Priority: Minor Labels: cql3, cqlsh Attachments: 0001-Allow-CQL-3.0-with-uppercase-SELECT-statement.patch, 4161.patch.txt Uppercase SELECT prevents usage of CQL 3.0 features like ORDER BY Example: select * from test ORDER BY number; # works SELECT * from test ORDER BY number; # fails -- 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-3909) Pig should handle wide rows
[ https://issues.apache.org/jira/browse/CASSANDRA-3909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257556#comment-13257556 ] Brandon Williams commented on CASSANDRA-3909: - bq. personally I do trust you on that this can't break anything 3 bq. I do however think that in general there would be some merit to stick to more strict rules. I agree, however my reasoning is thus: if we support wide rows in 1.1.0 (and we do) then why not pig? Pig should handle wide rows --- Key: CASSANDRA-3909 URL: https://issues.apache.org/jira/browse/CASSANDRA-3909 Project: Cassandra Issue Type: Bug Components: Hadoop Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.1.1 Attachments: 3909.txt Pig should be able to use the wide row support in CFIF. -- 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-4004) Add support for ReversedType
[
https://issues.apache.org/jira/browse/CASSANDRA-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257568#comment-13257568
]
Sylvain Lebresne commented on CASSANDRA-4004:
-
bq. This is what I'm referring to:
Wait, what happened to Third (and this is the big one) I strongly suspect that
we're going to start supporting at least limited run-time ordering in the near
future from CASSANDRA-3925. How can I reconcile that with The other relevant
context here is that we decided not to support arbitrary orderings?
bq. ORDER BY X DESC does not mean give me them in the reverse order that Xes
are in on disk
I *never* suggested that, not even a little. Not more than you did.
bq. it means give me larger values before smaller ones. This isn't open for
debate, it's a very clear requirement
Sure. But the definition of larger versus smaller depends on what ordering you
are talking about. This isn't open for debate either. Math have closed that
debate for ages. And SQL is not excluded from that rule, but it just happens
that SQL has default orderings (based on the column type) and you can't define
new ones. But we can do that in CQL. We can independently of this ticket
because of custom types.
Again, once you consider custom types (which we have), you can't hide behind
that the fact that value X is larger than Y depends on the ordering induces by
your custom types. That's the ASC order, and DESC is the reverse of that. If
someone define it's own custom types being reverseIntegerType, how can you
avoid SELECT ORDER BY DESC to not return 1 before 3? You can't, and returning 1
before 3 absolutely make sense because 1 is larger than 3 if the order is
'reverseInteger'.
bq. SQL and CQL are declarative languages: Here is what I want; you figure out
how to give me the results. This has proved a good design.
Sure, *nothing* in what I'm suggesting is at odd with that.
bq. Modifying the semantics of a query based on index or clustering
Again, I'm not suggesting any such thing at all. The semantic of a SELECT X
ORDER BY Y depends on what ordering relation is defined for Y *because the
ordering relation is what defines the order*. SQL has a limited and non
customizable set of types *and* (implicitly) define an ordering relation for
each one. If one type was 'thing' it would have to define the ordering of
'thing' otherwise ORDER BY queries wouldn't be properly defined. CQL also has a
default set of types which have associated ordering relation. I'm *only*
suggesting we add a simple syntax so that given a type/relation (a default one
or a custom one btw), we can define the type/ordering relation that validate
the same value but have the reversed ordering.
Add support for ReversedType
Key: CASSANDRA-4004
URL: https://issues.apache.org/jira/browse/CASSANDRA-4004
Project: Cassandra
Issue Type: Sub-task
Components: API
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Trivial
Fix For: 1.1.1
Attachments: 4004.txt
It would be nice to add a native syntax for the use of ReversedType. I'm sure
there is anything in SQL that we inspired ourselves from, so I would propose
something like:
{noformat}
CREATE TABLE timeseries (
key text,
time uuid,
value text,
PRIMARY KEY (key, time DESC)
)
{noformat}
Alternatively, the DESC could also be put after the column name definition
but one argument for putting it in the PK instead is that this only apply to
keys.
--
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-4004) Add support for ReversedType
[
https://issues.apache.org/jira/browse/CASSANDRA-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257580#comment-13257580
]
Jonathan Ellis commented on CASSANDRA-4004:
---
bq. what happened to Third (and this is the big one) I strongly suspect that
we're going to start supporting at least limited run-time ordering in the near
future from CASSANDRA-3925
Nothing, except that it's a separate ticket's worth of work.
bq. I never suggested that [ORDER BY depends on disk order], not even a little.
Not more than you did.
I really don't see the distinction between saying disk order and clustering
order, as in the clustered part of th PK induces an ordering of records ...
SELECT without ORDER BY should return records in that clustering order ...
SELECT ORDER BY ASC returns 'z' before 'a'.
But disk order or clustering order, I don't care which you call it; I reject
both as modifiers of the semantics of DESC.
bq. the fact that value X is larger than Y depends on the ordering induces by
your custom types
Agreed. But that's not the same as reverse-clustering on a type: y int ...
PRIMARY KEY (x, y DESC) (to use your syntax) is NOT the same as y ReversedInt
... PRIMARY KEY (x, y). In the former, ORDER BY Y DESC should give larger Y
before smaller; in the latter, the reverse.
Add support for ReversedType
Key: CASSANDRA-4004
URL: https://issues.apache.org/jira/browse/CASSANDRA-4004
Project: Cassandra
Issue Type: Sub-task
Components: API
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Trivial
Fix For: 1.1.1
Attachments: 4004.txt
It would be nice to add a native syntax for the use of ReversedType. I'm sure
there is anything in SQL that we inspired ourselves from, so I would propose
something like:
{noformat}
CREATE TABLE timeseries (
key text,
time uuid,
value text,
PRIMARY KEY (key, time DESC)
)
{noformat}
Alternatively, the DESC could also be put after the column name definition
but one argument for putting it in the PK instead is that this only apply to
keys.
--
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] [Issue Comment Edited] (CASSANDRA-4004) Add support for ReversedType
[
https://issues.apache.org/jira/browse/CASSANDRA-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257580#comment-13257580
]
Jonathan Ellis edited comment on CASSANDRA-4004 at 4/19/12 4:25 PM:
bq. what happened to Third (and this is the big one) I strongly suspect that
we're going to start supporting at least limited run-time ordering in the near
future from CASSANDRA-3925
Nothing, except that it's a separate ticket's worth of work.
bq. I never suggested that [ORDER BY depends on disk order], not even a little.
Not more than you did.
I really don't see the distinction between saying disk order and clustering
order, as in the clustered part of th PK induces an ordering of records ...
SELECT without ORDER BY should return records in that clustering order ...
SELECT ORDER BY ASC returns 'z' before 'a'.
But disk order or clustering order, I don't care which you call it; I reject
both as modifiers of the semantics of ASC and DESC. (But again, SELECT with no
explicit ORDER BY is free to return in any order we like.)
bq. the fact that value X is larger than Y depends on the ordering induces by
your custom types
Agreed. But that's not the same as reverse-clustering on a type: y int ...
PRIMARY KEY (x, y DESC) (to use your syntax) is NOT the same as y ReversedInt
... PRIMARY KEY (x, y). In the former, ORDER BY Y DESC should give larger Y
before smaller (that is, 100 before 1); in the latter, the reverse.
was (Author: jbellis):
bq. what happened to Third (and this is the big one) I strongly suspect
that we're going to start supporting at least limited run-time ordering in the
near future from CASSANDRA-3925
Nothing, except that it's a separate ticket's worth of work.
bq. I never suggested that [ORDER BY depends on disk order], not even a little.
Not more than you did.
I really don't see the distinction between saying disk order and clustering
order, as in the clustered part of th PK induces an ordering of records ...
SELECT without ORDER BY should return records in that clustering order ...
SELECT ORDER BY ASC returns 'z' before 'a'.
But disk order or clustering order, I don't care which you call it; I reject
both as modifiers of the semantics of DESC.
bq. the fact that value X is larger than Y depends on the ordering induces by
your custom types
Agreed. But that's not the same as reverse-clustering on a type: y int ...
PRIMARY KEY (x, y DESC) (to use your syntax) is NOT the same as y ReversedInt
... PRIMARY KEY (x, y). In the former, ORDER BY Y DESC should give larger Y
before smaller; in the latter, the reverse.
Add support for ReversedType
Key: CASSANDRA-4004
URL: https://issues.apache.org/jira/browse/CASSANDRA-4004
Project: Cassandra
Issue Type: Sub-task
Components: API
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Trivial
Fix For: 1.1.1
Attachments: 4004.txt
It would be nice to add a native syntax for the use of ReversedType. I'm sure
there is anything in SQL that we inspired ourselves from, so I would propose
something like:
{noformat}
CREATE TABLE timeseries (
key text,
time uuid,
value text,
PRIMARY KEY (key, time DESC)
)
{noformat}
Alternatively, the DESC could also be put after the column name definition
but one argument for putting it in the PK instead is that this only apply to
keys.
--
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-4161) CQL 3.0 does not work in cqlsh with uppercase SELECT
[ https://issues.apache.org/jira/browse/CASSANDRA-4161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257588#comment-13257588 ] Jonas Dohse commented on CASSANDRA-4161: +1 for 4161.patch.txt CQL 3.0 does not work in cqlsh with uppercase SELECT Key: CASSANDRA-4161 URL: https://issues.apache.org/jira/browse/CASSANDRA-4161 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1.0 Environment: cqlsh Reporter: Jonas Dohse Priority: Minor Labels: cql3, cqlsh Attachments: 0001-Allow-CQL-3.0-with-uppercase-SELECT-statement.patch, 4161.patch.txt Uppercase SELECT prevents usage of CQL 3.0 features like ORDER BY Example: select * from test ORDER BY number; # works SELECT * from test ORDER BY number; # fails -- 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-4004) Add support for ReversedType
[
https://issues.apache.org/jira/browse/CASSANDRA-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257619#comment-13257619
]
Sylvain Lebresne commented on CASSANDRA-4004:
-
bq. Nothing, except that it's a separate ticket's worth of work.
Oh ok. For the records I didn't implied otherwise.
bq. But that's not the same as reverse-clustering on a type: y int ... PRIMARY
KEY (x, y DESC) (to use your syntax) is NOT the same as y ReversedInt ...
PRIMARY KEY (x, y). In the former, ORDER BY Y DESC
What?! I said that I wasn't sure my syntax was good. But with all I've said I
expected it was clear that what I want to do with this ticket from day one is
to allow to define y ReversedInt ... PRIMARY KEY but without having to write
a custom java class since we don't have to and that is *exactly* what my patch
implements. I'm fine saying my syntax suck and allow to write is y
reversed(int) .. PK. But to be clear, I don't think that option is a bad fit
at all for CQL3, and that's not the C* veteran talk.
bq. In the former, ORDER BY Y DESC should give larger Y before smaller (that
is, 100 before 1); in the latter, the reverse
To my defence, you're attributing *your* semantic to *my* made up syntax (which
again, may be is counter-intuitive to you with your background but is really
not to me, and I made it clear that it was a suggestion. I even said in the
description that Alternatively, the DESC could also be put after the column
name definition).
bq. I really don't see the distinction between saying disk order and
clustering order, as in the clustered part of th PK induces an ordering of
records ...
Maybe with the reversed(int) syntax it makes it more clear, but when I talk
about ordering of records, I'm saying that we should say that in CQL the model
defines an ordering of the rows (where rows is in the sense of SQL) in tables,
order that is defined as the ordering implied by the types of the clustered
keys (and to be clear, I don't care what clustering mean in SQL, I'm reusing
the name because you're using it, but I *only* mean by that term the fields in
the PK after the first one). That doesn't imply the disk order has to respect
it (though it will but that's an implementation detail). In other words, and
somewhat unrelated to this issue, I think there would be value to say that the
order of SELECT without any ORDER BY is something defined by CQL (while SQL
does not do that). I think there would be value because I think it helps
understanding which model are a good fit for CQL.
Now, and to sum up, I think that having the y reversed(int) syntax has the
following advantages over just allowing to change the on-disk order:
# I do think that in most case it's more natural to define a reversed type
rather than just adding an optim for reversed queries. Typically, it means that
'y reversed(myCustomType)' is the same than 'y myReversedCustomType' which
has a nice consistency to it. In the alternative, and even though I'm *not*
saying it's ill defined in any way, I do think that have a form of syntactic
double negation that is not equivalent to removing both is kind of weird.
# Though that seems to be very clear to you, I do think that it's not
necessarily clear per se (i.e to anyone that may not be familiar with SQL
clustering for instance) that WITH CLUSTERING ORDER (x DESC) does not change
the ordering (and by that I mean 'does not semantically mean x
reversed(type)').
# With that solution, we can maintain (without doing anything) the fact that a
select without ORDERING respect the ordering implied by the clustering. I
think it's convenient for C*. Again, lots of efficient model for C* uses that
ordering, so it feels like a better idea to say 'oh, and contrarily to SQL the
order of records in a table is defined (and thus the default ordering or
SELECT) and lots of good modeling pattern for C* rely on this'.
Add support for ReversedType
Key: CASSANDRA-4004
URL: https://issues.apache.org/jira/browse/CASSANDRA-4004
Project: Cassandra
Issue Type: Sub-task
Components: API
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Trivial
Fix For: 1.1.1
Attachments: 4004.txt
It would be nice to add a native syntax for the use of ReversedType. I'm sure
there is anything in SQL that we inspired ourselves from, so I would propose
something like:
{noformat}
CREATE TABLE timeseries (
key text,
time uuid,
value text,
PRIMARY KEY (key, time DESC)
)
{noformat}
Alternatively, the DESC could also be put after the column name definition
but one argument for putting it in the PK instead is that this only apply to
keys.
--
This message is automatically generated by JIRA.
If you think it was sent
[jira] [Commented] (CASSANDRA-4004) Add support for ReversedType
[
https://issues.apache.org/jira/browse/CASSANDRA-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257663#comment-13257663
]
Jonathan Ellis commented on CASSANDRA-4004:
---
bq. the model defines an ordering of the rows (where rows is in the sense of
SQL) in tables, order that is defined as the ordering implied by the types of
the clustered keys (and to be clear, I don't care what clustering mean in
SQL, I'm reusing the name because you're using it, but I only mean by that term
the fields in the PK after the first one). That doesn't imply the disk order
has to respect it
I think the mental model of rows as predicates, queries returning sets of rows
with no inherent order, and ORDER BY as specifying the desired order, is much
simpler and easier to reason about (see prior point about having to consult DDL
+ QUERY to figure out what order results are supposed to appear in).
bq. To my defence, you're attributing your semantic to my made up syntax
I was trying to say that I view ReversedType(Int32Type) as modification of
Int32Type (which should not affect int ordering) and not a completely new type,
the way the (hypothetical) ReversedInt (or BackwardsInt, or AlmostNotQuiteInt)
type would be. Since the latter isn't really related to an int at all, even
though they look a lot like ints in many respects.
bq. I do think that in most case it's more natural to define a reversed type
rather than just adding an optim for reversed queries.
I don't follow.
bq. I do think that have a form of syntactic double negation that is not
equivalent to removing both is kind of weird... I do think that it's not
necessarily clear per se (i.e to anyone that may not be familiar with SQL
clustering for instance) that WITH CLUSTERING ORDER (x DESC) does not change
the ordering
But saying {{ORDER BY X DESC}} always gives you higher X first is the only
way to avoid the double negation! Otherwise in your original syntax of PK (X,
Y DESC), the only way to get 1 to sort before 100 is to ask for ORDER BY Y DESC
so the DESC cancel out!
I just can't agree that ORDER BY Y DESC giving {1, 100} is going to be less
confusing than {100, 1}, no matter how much we tell users, No, you see, it's
really just reversing the clustering order, which you already reversed...
Users may not be familiar with clustering, but they're *very* familiar with
ORDER BY, which as I said above, is very clear on what it does. Clustering is
the closest example of how performance hints should *not* change the semantics
of the query, but indexes fall into the same category.
It may also be worth pointing out that it's worth preserving CQL compatibility
with Hive; queries that execute on both (and to the best of my knowledge CQL3
is a strict subset of Hive SQL) should not give different results.
Add support for ReversedType
Key: CASSANDRA-4004
URL: https://issues.apache.org/jira/browse/CASSANDRA-4004
Project: Cassandra
Issue Type: Sub-task
Components: API
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Trivial
Fix For: 1.1.1
Attachments: 4004.txt
It would be nice to add a native syntax for the use of ReversedType. I'm sure
there is anything in SQL that we inspired ourselves from, so I would propose
something like:
{noformat}
CREATE TABLE timeseries (
key text,
time uuid,
value text,
PRIMARY KEY (key, time DESC)
)
{noformat}
Alternatively, the DESC could also be put after the column name definition
but one argument for putting it in the PK instead is that this only apply to
keys.
--
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] [Issue Comment Edited] (CASSANDRA-4004) Add support for ReversedType
[
https://issues.apache.org/jira/browse/CASSANDRA-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257663#comment-13257663
]
Jonathan Ellis edited comment on CASSANDRA-4004 at 4/19/12 6:22 PM:
bq. the model defines an ordering of the rows (where rows is in the sense of
SQL) in tables, order that is defined as the ordering implied by the types of
the clustered keys (and to be clear, I don't care what clustering mean in
SQL, I'm reusing the name because you're using it, but I only mean by that term
the fields in the PK after the first one). That doesn't imply the disk order
has to respect it
I think the mental model of rows as predicates, queries returning sets of rows
with no inherent order, and ORDER BY as specifying the desired order, is much
simpler and easier to reason about (see prior point about having to consult DDL
+ QUERY to figure out what order results are supposed to appear in).
bq. To my defence, you're attributing your semantic to my made up syntax
I was trying to say that I view ReversedType(Int32Type) as modification of
Int32Type (which should not affect int ordering) and not a completely new type,
the way the (hypothetical) ReversedInt (or BackwardsInt, or AlmostNotQuiteInt)
type would be. Since the latter isn't really related to an int at all, even
though they look a lot like ints in many respects.
bq. I do think that in most case it's more natural to define a reversed type
rather than just adding an optim for reversed queries.
I don't follow.
bq. I do think that have a form of syntactic double negation that is not
equivalent to removing both is kind of weird... I do think that it's not
necessarily clear per se (i.e to anyone that may not be familiar with SQL
clustering for instance) that WITH CLUSTERING ORDER (x DESC) does not change
the ordering
But saying {{ORDER BY X DESC}} always gives you higher X first (and ASC
always gives you lower first) is the only way to avoid the double negation!
Otherwise in your original syntax of PK (X, Y DESC), the only way to get 1 to
sort before 100 is to ask for ORDER BY Y DESC so the DESC cancel out!
I just can't agree that ORDER BY Y DESC giving {1, 100} is going to be less
confusing than {100, 1}, no matter how much we tell users, No, you see, it's
really just reversing the clustering order, which you already reversed...
Users may not be familiar with clustering, but they're *very* familiar with
ORDER BY, which as I said above, is very clear on what it does. Clustering is
the closest example of how performance hints should *not* change the semantics
of the query, but indexes fall into the same category.
It may also be worth pointing out that it's worth preserving CQL compatibility
with Hive; queries that execute on both (and to the best of my knowledge CQL3
is a strict subset of Hive SQL) should not give different results.
was (Author: jbellis):
bq. the model defines an ordering of the rows (where rows is in the sense
of SQL) in tables, order that is defined as the ordering implied by the types
of the clustered keys (and to be clear, I don't care what clustering mean in
SQL, I'm reusing the name because you're using it, but I only mean by that term
the fields in the PK after the first one). That doesn't imply the disk order
has to respect it
I think the mental model of rows as predicates, queries returning sets of rows
with no inherent order, and ORDER BY as specifying the desired order, is much
simpler and easier to reason about (see prior point about having to consult DDL
+ QUERY to figure out what order results are supposed to appear in).
bq. To my defence, you're attributing your semantic to my made up syntax
I was trying to say that I view ReversedType(Int32Type) as modification of
Int32Type (which should not affect int ordering) and not a completely new type,
the way the (hypothetical) ReversedInt (or BackwardsInt, or AlmostNotQuiteInt)
type would be. Since the latter isn't really related to an int at all, even
though they look a lot like ints in many respects.
bq. I do think that in most case it's more natural to define a reversed type
rather than just adding an optim for reversed queries.
I don't follow.
bq. I do think that have a form of syntactic double negation that is not
equivalent to removing both is kind of weird... I do think that it's not
necessarily clear per se (i.e to anyone that may not be familiar with SQL
clustering for instance) that WITH CLUSTERING ORDER (x DESC) does not change
the ordering
But saying {{ORDER BY X DESC}} always gives you higher X first is the only
way to avoid the double negation! Otherwise in your original syntax of PK (X,
Y DESC), the only way to get 1 to sort before 100 is to ask for ORDER BY Y DESC
so the DESC cancel out!
I just can't agree that ORDER BY Y DESC giving {1, 100} is
[jira] [Updated] (CASSANDRA-4163) CQL3 ALTER TABLE command causes NPE
[ https://issues.apache.org/jira/browse/CASSANDRA-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-4163: --- Attachment: 4163.patch-2.txt K, attached and updated in github. CQL3 ALTER TABLE command causes NPE --- Key: CASSANDRA-4163 URL: https://issues.apache.org/jira/browse/CASSANDRA-4163 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.0 Environment: INFO 16:07:11,757 Cassandra version: 1.1.0-rc1-SNAPSHOT INFO 16:07:11,757 Thrift API version: 19.30.0 INFO 16:07:11,758 CQL supported versions: 2.0.0,3.0.0-beta1 (default: 2.0.0) Reporter: Kristine Hahn Assignee: paul cannon Labels: cql3 Fix For: 1.1.0 Attachments: 4163.patch-2.txt, 4163.patch.txt To reproduce the problem: ./cqlsh --cql3 Connected to Test Cluster at localhost:9160. [cqlsh 2.2.0 | Cassandra 1.1.0-rc1-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol 19.30.0] Use HELP for help. cqlsh CREATE KEYSPACE test34 WITH strategy_class = 'org.apache.cassandra.locator.SimpleStrategy' AND strategy_options:replication_factor='1'; cqlsh USE test34; cqlsh:test34 CREATE TABLE users ( ... password varchar, ... gender varchar, ... session_token varchar, ... state varchar, ... birth_year bigint, ... pk varchar, ... PRIMARY KEY (pk) ... ); cqlsh:test34 ALTER TABLE users ADD coupon_code varchar; TSocket read 0 bytes -- 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-4163) CQL3 ALTER TABLE command causes NPE
[ https://issues.apache.org/jira/browse/CASSANDRA-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257675#comment-13257675 ] paul cannon commented on CASSANDRA-4163: Link for the new tag (it's on the same branch, though): http://github.com/thepaul/cassandra/tree/pending/4163-2 CQL3 ALTER TABLE command causes NPE --- Key: CASSANDRA-4163 URL: https://issues.apache.org/jira/browse/CASSANDRA-4163 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.0 Environment: INFO 16:07:11,757 Cassandra version: 1.1.0-rc1-SNAPSHOT INFO 16:07:11,757 Thrift API version: 19.30.0 INFO 16:07:11,758 CQL supported versions: 2.0.0,3.0.0-beta1 (default: 2.0.0) Reporter: Kristine Hahn Assignee: paul cannon Labels: cql3 Fix For: 1.1.0 Attachments: 4163.patch-2.txt, 4163.patch.txt To reproduce the problem: ./cqlsh --cql3 Connected to Test Cluster at localhost:9160. [cqlsh 2.2.0 | Cassandra 1.1.0-rc1-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol 19.30.0] Use HELP for help. cqlsh CREATE KEYSPACE test34 WITH strategy_class = 'org.apache.cassandra.locator.SimpleStrategy' AND strategy_options:replication_factor='1'; cqlsh USE test34; cqlsh:test34 CREATE TABLE users ( ... password varchar, ... gender varchar, ... session_token varchar, ... state varchar, ... birth_year bigint, ... pk varchar, ... PRIMARY KEY (pk) ... ); cqlsh:test34 ALTER TABLE users ADD coupon_code varchar; TSocket read 0 bytes -- 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-4173) cqlsh: in cql3 mode, use cql3 quoting when outputting cql
cqlsh: in cql3 mode, use cql3 quoting when outputting cql
-
Key: CASSANDRA-4173
URL: https://issues.apache.org/jira/browse/CASSANDRA-4173
Project: Cassandra
Issue Type: Improvement
Components: Tools
Affects Versions: 1.1.0
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
when cqlsh needs to output a column name or other term which needs quoting
(say, if you run DESCRIBE KEYSPACE and some column name has a space in it), it
currently only knows how to quote in the cql2 way. That is,
{noformat}
cqlsh:foo describe columnfamily bar
CREATE COLUMNFAMILY bar (
a int PRIMARY KEY,
'b c' text
) WITH
...
{noformat}
cql3 does not recognize single quotes around column names, or columnfamily or
keyspace names either. cqlsh ought to learn how to use double-quotes instead
when in cql3 mode.
--
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-4164) Cqlsh should support DESCRIBE on cql3-style composite CFs
[
https://issues.apache.org/jira/browse/CASSANDRA-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon updated CASSANDRA-4164:
---
Labels: cql3 (was: )
Summary: Cqlsh should support DESCRIBE on cql3-style composite CFs (was:
Bug with 'describe columnfamily' in cql(sh?))
Cqlsh should support DESCRIBE on cql3-style composite CFs
-
Key: CASSANDRA-4164
URL: https://issues.apache.org/jira/browse/CASSANDRA-4164
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Nick Bailey
Assignee: paul cannon
Labels: cql3
Fix For: 1.1.0
There is a discrepancy between create column family commands and then the
output of the describe command:
{noformat}
cqlsh:test CREATE TABLE timeline (
... user_id varchar,
... tweet_id uuid,
... author varchar,
... body varchar,
... PRIMARY KEY (user_id, tweet_id)
... );
cqlsh:test describe columnfamily timeline;
CREATE COLUMNFAMILY timeline (
user_id text PRIMARY KEY
) WITH
comment='' AND
comparator='CompositeType(org.apache.cassandra.db.marshal.UUIDType,org.apache.cassandra.db.marshal.UTF8Type)'
AND
read_repair_chance=0.10 AND
gc_grace_seconds=864000 AND
default_validation=text 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='org.apache.cassandra.io.compress.SnappyCompressor';
{noformat}
--
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-4173) cqlsh: in cql3 mode, use cql3 quoting when outputting cql
[
https://issues.apache.org/jira/browse/CASSANDRA-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257757#comment-13257757
]
Jonathan Ellis commented on CASSANDRA-4173:
---
Does CQL2 support double quotes? If so, switching to doublequotes everywhere
may be simpler.
cqlsh: in cql3 mode, use cql3 quoting when outputting cql
-
Key: CASSANDRA-4173
URL: https://issues.apache.org/jira/browse/CASSANDRA-4173
Project: Cassandra
Issue Type: Improvement
Components: Tools
Affects Versions: 1.1.0
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
Labels: cql3, cqlsh
when cqlsh needs to output a column name or other term which needs quoting
(say, if you run DESCRIBE KEYSPACE and some column name has a space in it),
it currently only knows how to quote in the cql2 way. That is,
{noformat}
cqlsh:foo describe columnfamily bar
CREATE COLUMNFAMILY bar (
a int PRIMARY KEY,
'b c' text
) WITH
...
{noformat}
cql3 does not recognize single quotes around column names, or columnfamily or
keyspace names either. cqlsh ought to learn how to use double-quotes instead
when in cql3 mode.
--
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-4174) Unnecessary compaction happens when streaming
Unnecessary compaction happens when streaming - Key: CASSANDRA-4174 URL: https://issues.apache.org/jira/browse/CASSANDRA-4174 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0.0 Reporter: Yuki Morishita Assignee: Yuki Morishita Priority: Minor Fix For: 1.0.10 When streaming session finishes, streamed sstabls are added to CFS one by one using ColumnFamilyStore#addSSTable(https://github.com/apache/cassandra/blob/cassandra-1.0.9/src/java/org/apache/cassandra/streaming/StreamInSession.java#L141). This method submits compaction in background(https://github.com/apache/cassandra/blob/cassandra-1.0.9/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L946), and end up with unnecessary compaction tasks behind. -- 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-4174) Unnecessary compaction happens when streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-4174: -- Attachment: 4174-1.0.txt Patch attached for 1.0 branch. I'm not sure if submitting compaction in background is necessary at all. Unnecessary compaction happens when streaming - Key: CASSANDRA-4174 URL: https://issues.apache.org/jira/browse/CASSANDRA-4174 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0.0 Reporter: Yuki Morishita Assignee: Yuki Morishita Priority: Minor Fix For: 1.0.10 Attachments: 4174-1.0.txt When streaming session finishes, streamed sstabls are added to CFS one by one using ColumnFamilyStore#addSSTable(https://github.com/apache/cassandra/blob/cassandra-1.0.9/src/java/org/apache/cassandra/streaming/StreamInSession.java#L141). This method submits compaction in background(https://github.com/apache/cassandra/blob/cassandra-1.0.9/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L946), and end up with unnecessary compaction tasks behind. -- 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-4174) Unnecessary compaction happens when streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257794#comment-13257794 ] Jonathan Ellis commented on CASSANDRA-4174: --- Are you proposing we issue a single compaction submission when streaming is done, instead? Unnecessary compaction happens when streaming - Key: CASSANDRA-4174 URL: https://issues.apache.org/jira/browse/CASSANDRA-4174 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0.0 Reporter: Yuki Morishita Assignee: Yuki Morishita Priority: Minor Fix For: 1.0.10 Attachments: 4174-1.0.txt When streaming session finishes, streamed sstabls are added to CFS one by one using ColumnFamilyStore#addSSTable(https://github.com/apache/cassandra/blob/cassandra-1.0.9/src/java/org/apache/cassandra/streaming/StreamInSession.java#L141). This method submits compaction in background(https://github.com/apache/cassandra/blob/cassandra-1.0.9/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L946), and end up with unnecessary compaction tasks behind. -- 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] [Issue Comment Edited] (CASSANDRA-4174) Unnecessary compaction happens when streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257795#comment-13257795 ] Yuki Morishita edited comment on CASSANDRA-4174 at 4/19/12 8:45 PM: bq. Are you proposing we issue a single compaction submission when streaming is done, instead? Yes. Patch attached for 1.0 branch. I'm not sure if submitting compaction in background is necessary at all. was (Author: yukim): Patch attached for 1.0 branch. I'm not sure if submitting compaction in background is necessary at all. Unnecessary compaction happens when streaming - Key: CASSANDRA-4174 URL: https://issues.apache.org/jira/browse/CASSANDRA-4174 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0.0 Reporter: Yuki Morishita Assignee: Yuki Morishita Priority: Minor Fix For: 1.0.10 Attachments: 4174-1.0.txt When streaming session finishes, streamed sstabls are added to CFS one by one using ColumnFamilyStore#addSSTable(https://github.com/apache/cassandra/blob/cassandra-1.0.9/src/java/org/apache/cassandra/streaming/StreamInSession.java#L141). This method submits compaction in background(https://github.com/apache/cassandra/blob/cassandra-1.0.9/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L946), and end up with unnecessary compaction tasks behind. -- 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
[1/9] git commit: Merge branch 'cassandra-1.1' into trunk
Updated Branches: refs/heads/cassandra-1.1 991c2a25b - 5cd473632 refs/heads/cassandra-1.1.0 43a472e13 - 36a9f9bd8 refs/heads/trunk 9b6156ba7 - 7b3349f6e Merge branch 'cassandra-1.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7b3349f6 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7b3349f6 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7b3349f6 Branch: refs/heads/trunk Commit: 7b3349f6ece013b2c17644ddad6ba87ab2ba5105 Parents: 9b6156b 5cd4736 Author: Jonathan Ellis jbel...@apache.org Authored: Thu Apr 19 15:54:06 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Thu Apr 19 15:54:06 2012 -0500 -- CHANGES.txt|2 ++ bin/cqlsh |2 +- build.xml | 12 +--- src/java/org/apache/cassandra/cql3/Cql.g |4 +--- .../cql3/statements/AlterTableStatement.java |2 +- 5 files changed, 10 insertions(+), 12 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/7b3349f6/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/7b3349f6/build.xml -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/7b3349f6/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java --
[4/9] git commit: fix NPE in cql3 ALTER TABLE patch by pcannon; reviewed by jbellis for CASSANDRA-4163
fix NPE in cql3 ALTER TABLE
patch by pcannon; reviewed by jbellis for CASSANDRA-4163
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/36a9f9bd
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/36a9f9bd
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/36a9f9bd
Branch: refs/heads/trunk
Commit: 36a9f9bd8f70b35a13fe510576635c619b2b81ff
Parents: dc975e8
Author: Jonathan Ellis jbel...@apache.org
Authored: Thu Apr 19 15:53:53 2012 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Apr 19 15:53:53 2012 -0500
--
CHANGES.txt|1 +
build.xml | 12 +---
src/java/org/apache/cassandra/cql3/Cql.g |4 +---
.../cql3/statements/AlterTableStatement.java |2 +-
4 files changed, 8 insertions(+), 11 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/36a9f9bd/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 8a9d924..5e84e66 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
1.1-dev
+ * fix NPE in cql3 ALTER TABLE (CASSANDRA-4163)
* (cqlsh) fix recognizing uppercase SELECT keyword (CASSANDRA-4161)
* average a reduced liveRatio estimate with the previous one (CASSANDRA-4065)
* Allow KS and CF names up to 48 characters (CASSANDRA-4157)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/36a9f9bd/build.xml
--
diff --git a/build.xml b/build.xml
index 6ec0cde..89f3bc2 100644
--- a/build.xml
+++ b/build.xml
@@ -190,16 +190,14 @@
This generates the CQL grammar files from Cql.g
--
target name=check-gen-cql-grammar
- uptodate property=cqlcurrent
-srcfile=${build.src.java}/org/apache/cassandra/cql/Cql.g
-
targetfile=${build.src.gen-java}/org/apache/cassandra/cql/Cql.tokens/
- uptodate property=cqlcurrent
-srcfile=${build.src.java}/org/apache/cassandra/cql3/Cql.g
-
targetfile=${build.src.gen-java}/org/apache/cassandra/cql3/Cql.tokens/
+ uptodate property=cqlcurrent
+srcfiles dir=${build.src.java}
includes=org/apache/cassandra/cql*/Cql.g/
+mapper type=glob from=*.g to=*.tokens/
+ /uptodate
/target
target name=gen-cql-grammar depends=check-gen-cql-grammar
unless=cqlcurrent
- echoBuilding Grammar ${build.src.java}/org/apache/cassandra/cql/Cql.g
.../echo
+ echoBuilding Grammar ${build.src.java}/org/apache/cassandra/cql*/Cql.g
.../echo
java classname=org.antlr.Tool
classpath=${build.lib}/antlr-3.2.jar
fork=true
http://git-wip-us.apache.org/repos/asf/cassandra/blob/36a9f9bd/src/java/org/apache/cassandra/cql3/Cql.g
--
diff --git a/src/java/org/apache/cassandra/cql3/Cql.g
b/src/java/org/apache/cassandra/cql3/Cql.g
index cb15272..f1b4718 100644
--- a/src/java/org/apache/cassandra/cql3/Cql.g
+++ b/src/java/org/apache/cassandra/cql3/Cql.g
@@ -362,9 +362,7 @@ createIndexStatement returns [CreateIndexStatement expr]
alterTableStatement returns [AlterTableStatement expr]
@init {
AlterTableStatement.Type type = null;
-String validator = null;
-ColumnIdentifier columnName = null;
-MapString, String propertyMap = null;
+props = new HashMapString, String();
}
: K_ALTER K_COLUMNFAMILY cf=columnFamilyName
( K_ALTER id=cident K_TYPE v=comparatorType { type =
AlterTableStatement.Type.ALTER; }
http://git-wip-us.apache.org/repos/asf/cassandra/blob/36a9f9bd/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
--
diff --git
a/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
index 1ecbd8a..37db2fd 100644
--- a/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
@@ -47,7 +47,7 @@ public class AlterTableStatement extends
SchemaAlteringStatement
{
super(name);
this.oType = type;
-this.columnName = null;
+this.columnName = columnName;
this.validator = validator; // used only for ADD/ALTER commands
this.cfProps.addAll(propertyMap);
}
[3/9] git commit: Merge branch 'cassandra-1.1.0' into cassandra-1.1
Merge branch 'cassandra-1.1.0' into cassandra-1.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5cd47363 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5cd47363 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5cd47363 Branch: refs/heads/trunk Commit: 5cd473632355fc75087f936a03353cb560f58f76 Parents: 991c2a2 36a9f9b Author: Jonathan Ellis jbel...@apache.org Authored: Thu Apr 19 15:53:59 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Thu Apr 19 15:53:59 2012 -0500 -- CHANGES.txt|2 ++ bin/cqlsh |2 +- build.xml | 12 +--- src/java/org/apache/cassandra/cql3/Cql.g |4 +--- .../cql3/statements/AlterTableStatement.java |2 +- 5 files changed, 10 insertions(+), 12 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/5cd47363/CHANGES.txt -- diff --cc CHANGES.txt index a6178d0,5e84e66..16b2165 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,22 -1,6 +1,24 @@@ +1.1.1-dev + * add -cf option to nodetool snapshot, and takeColumnFamilySnapshot to + StorageService mbean (CASSANDRA-556) + * optimize cleanup to drop entire sstables where possible (CASSANDRA-4079) + * optimize truncate when autosnapshot is disabled (CASSANDRA-4153) + * add support for commitlog archiving and point-in-time recovery + (CASSANDRA-3647) + * update caches to use byte[] keys to reduce memory overhead (CASSANDRA-3966) + * add column limit to cli (CASSANDRA-3012, 4098) + * clean up and optimize DataOutputBuffer, used by CQL compression and + CompositeType (CASSANDRA-4072) + * optimize commitlog checksumming (CASSANDRA-3610) + * identify and blacklist corrupted SSTables from future compactions + (CASSANDRA-2261) + * Move CfDef and KsDef validation out of thrift (CASSANDRA-4037) + * Expose repairing by a user provided range (CASSANDRA-3912) + + 1.1-dev + * fix NPE in cql3 ALTER TABLE (CASSANDRA-4163) + * (cqlsh) fix recognizing uppercase SELECT keyword (CASSANDRA-4161) * average a reduced liveRatio estimate with the previous one (CASSANDRA-4065) * Allow KS and CF names up to 48 characters (CASSANDRA-4157) * Add support for CL.TWO and CL.THREE in CQL (CASSANDRA-4156)
[2/9] git commit: Merge branch 'cassandra-1.1.0' into cassandra-1.1
Merge branch 'cassandra-1.1.0' into cassandra-1.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5cd47363 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5cd47363 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5cd47363 Branch: refs/heads/cassandra-1.1 Commit: 5cd473632355fc75087f936a03353cb560f58f76 Parents: 991c2a2 36a9f9b Author: Jonathan Ellis jbel...@apache.org Authored: Thu Apr 19 15:53:59 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Thu Apr 19 15:53:59 2012 -0500 -- CHANGES.txt|2 ++ bin/cqlsh |2 +- build.xml | 12 +--- src/java/org/apache/cassandra/cql3/Cql.g |4 +--- .../cql3/statements/AlterTableStatement.java |2 +- 5 files changed, 10 insertions(+), 12 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/5cd47363/CHANGES.txt -- diff --cc CHANGES.txt index a6178d0,5e84e66..16b2165 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,22 -1,6 +1,24 @@@ +1.1.1-dev + * add -cf option to nodetool snapshot, and takeColumnFamilySnapshot to + StorageService mbean (CASSANDRA-556) + * optimize cleanup to drop entire sstables where possible (CASSANDRA-4079) + * optimize truncate when autosnapshot is disabled (CASSANDRA-4153) + * add support for commitlog archiving and point-in-time recovery + (CASSANDRA-3647) + * update caches to use byte[] keys to reduce memory overhead (CASSANDRA-3966) + * add column limit to cli (CASSANDRA-3012, 4098) + * clean up and optimize DataOutputBuffer, used by CQL compression and + CompositeType (CASSANDRA-4072) + * optimize commitlog checksumming (CASSANDRA-3610) + * identify and blacklist corrupted SSTables from future compactions + (CASSANDRA-2261) + * Move CfDef and KsDef validation out of thrift (CASSANDRA-4037) + * Expose repairing by a user provided range (CASSANDRA-3912) + + 1.1-dev + * fix NPE in cql3 ALTER TABLE (CASSANDRA-4163) + * (cqlsh) fix recognizing uppercase SELECT keyword (CASSANDRA-4161) * average a reduced liveRatio estimate with the previous one (CASSANDRA-4065) * Allow KS and CF names up to 48 characters (CASSANDRA-4157) * Add support for CL.TWO and CL.THREE in CQL (CASSANDRA-4156)
[5/9] git commit: fix NPE in cql3 ALTER TABLE patch by pcannon; reviewed by jbellis for CASSANDRA-4163
fix NPE in cql3 ALTER TABLE
patch by pcannon; reviewed by jbellis for CASSANDRA-4163
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/36a9f9bd
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/36a9f9bd
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/36a9f9bd
Branch: refs/heads/cassandra-1.1.0
Commit: 36a9f9bd8f70b35a13fe510576635c619b2b81ff
Parents: dc975e8
Author: Jonathan Ellis jbel...@apache.org
Authored: Thu Apr 19 15:53:53 2012 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Apr 19 15:53:53 2012 -0500
--
CHANGES.txt|1 +
build.xml | 12 +---
src/java/org/apache/cassandra/cql3/Cql.g |4 +---
.../cql3/statements/AlterTableStatement.java |2 +-
4 files changed, 8 insertions(+), 11 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/36a9f9bd/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 8a9d924..5e84e66 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
1.1-dev
+ * fix NPE in cql3 ALTER TABLE (CASSANDRA-4163)
* (cqlsh) fix recognizing uppercase SELECT keyword (CASSANDRA-4161)
* average a reduced liveRatio estimate with the previous one (CASSANDRA-4065)
* Allow KS and CF names up to 48 characters (CASSANDRA-4157)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/36a9f9bd/build.xml
--
diff --git a/build.xml b/build.xml
index 6ec0cde..89f3bc2 100644
--- a/build.xml
+++ b/build.xml
@@ -190,16 +190,14 @@
This generates the CQL grammar files from Cql.g
--
target name=check-gen-cql-grammar
- uptodate property=cqlcurrent
-srcfile=${build.src.java}/org/apache/cassandra/cql/Cql.g
-
targetfile=${build.src.gen-java}/org/apache/cassandra/cql/Cql.tokens/
- uptodate property=cqlcurrent
-srcfile=${build.src.java}/org/apache/cassandra/cql3/Cql.g
-
targetfile=${build.src.gen-java}/org/apache/cassandra/cql3/Cql.tokens/
+ uptodate property=cqlcurrent
+srcfiles dir=${build.src.java}
includes=org/apache/cassandra/cql*/Cql.g/
+mapper type=glob from=*.g to=*.tokens/
+ /uptodate
/target
target name=gen-cql-grammar depends=check-gen-cql-grammar
unless=cqlcurrent
- echoBuilding Grammar ${build.src.java}/org/apache/cassandra/cql/Cql.g
.../echo
+ echoBuilding Grammar ${build.src.java}/org/apache/cassandra/cql*/Cql.g
.../echo
java classname=org.antlr.Tool
classpath=${build.lib}/antlr-3.2.jar
fork=true
http://git-wip-us.apache.org/repos/asf/cassandra/blob/36a9f9bd/src/java/org/apache/cassandra/cql3/Cql.g
--
diff --git a/src/java/org/apache/cassandra/cql3/Cql.g
b/src/java/org/apache/cassandra/cql3/Cql.g
index cb15272..f1b4718 100644
--- a/src/java/org/apache/cassandra/cql3/Cql.g
+++ b/src/java/org/apache/cassandra/cql3/Cql.g
@@ -362,9 +362,7 @@ createIndexStatement returns [CreateIndexStatement expr]
alterTableStatement returns [AlterTableStatement expr]
@init {
AlterTableStatement.Type type = null;
-String validator = null;
-ColumnIdentifier columnName = null;
-MapString, String propertyMap = null;
+props = new HashMapString, String();
}
: K_ALTER K_COLUMNFAMILY cf=columnFamilyName
( K_ALTER id=cident K_TYPE v=comparatorType { type =
AlterTableStatement.Type.ALTER; }
http://git-wip-us.apache.org/repos/asf/cassandra/blob/36a9f9bd/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
--
diff --git
a/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
index 1ecbd8a..37db2fd 100644
--- a/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
@@ -47,7 +47,7 @@ public class AlterTableStatement extends
SchemaAlteringStatement
{
super(name);
this.oType = type;
-this.columnName = null;
+this.columnName = columnName;
this.validator = validator; // used only for ADD/ALTER commands
this.cfProps.addAll(propertyMap);
}
[6/9] git commit: fix NPE in cql3 ALTER TABLE patch by pcannon; reviewed by jbellis for CASSANDRA-4163
fix NPE in cql3 ALTER TABLE
patch by pcannon; reviewed by jbellis for CASSANDRA-4163
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/36a9f9bd
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/36a9f9bd
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/36a9f9bd
Branch: refs/heads/cassandra-1.1
Commit: 36a9f9bd8f70b35a13fe510576635c619b2b81ff
Parents: dc975e8
Author: Jonathan Ellis jbel...@apache.org
Authored: Thu Apr 19 15:53:53 2012 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Apr 19 15:53:53 2012 -0500
--
CHANGES.txt|1 +
build.xml | 12 +---
src/java/org/apache/cassandra/cql3/Cql.g |4 +---
.../cql3/statements/AlterTableStatement.java |2 +-
4 files changed, 8 insertions(+), 11 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/36a9f9bd/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 8a9d924..5e84e66 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
1.1-dev
+ * fix NPE in cql3 ALTER TABLE (CASSANDRA-4163)
* (cqlsh) fix recognizing uppercase SELECT keyword (CASSANDRA-4161)
* average a reduced liveRatio estimate with the previous one (CASSANDRA-4065)
* Allow KS and CF names up to 48 characters (CASSANDRA-4157)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/36a9f9bd/build.xml
--
diff --git a/build.xml b/build.xml
index 6ec0cde..89f3bc2 100644
--- a/build.xml
+++ b/build.xml
@@ -190,16 +190,14 @@
This generates the CQL grammar files from Cql.g
--
target name=check-gen-cql-grammar
- uptodate property=cqlcurrent
-srcfile=${build.src.java}/org/apache/cassandra/cql/Cql.g
-
targetfile=${build.src.gen-java}/org/apache/cassandra/cql/Cql.tokens/
- uptodate property=cqlcurrent
-srcfile=${build.src.java}/org/apache/cassandra/cql3/Cql.g
-
targetfile=${build.src.gen-java}/org/apache/cassandra/cql3/Cql.tokens/
+ uptodate property=cqlcurrent
+srcfiles dir=${build.src.java}
includes=org/apache/cassandra/cql*/Cql.g/
+mapper type=glob from=*.g to=*.tokens/
+ /uptodate
/target
target name=gen-cql-grammar depends=check-gen-cql-grammar
unless=cqlcurrent
- echoBuilding Grammar ${build.src.java}/org/apache/cassandra/cql/Cql.g
.../echo
+ echoBuilding Grammar ${build.src.java}/org/apache/cassandra/cql*/Cql.g
.../echo
java classname=org.antlr.Tool
classpath=${build.lib}/antlr-3.2.jar
fork=true
http://git-wip-us.apache.org/repos/asf/cassandra/blob/36a9f9bd/src/java/org/apache/cassandra/cql3/Cql.g
--
diff --git a/src/java/org/apache/cassandra/cql3/Cql.g
b/src/java/org/apache/cassandra/cql3/Cql.g
index cb15272..f1b4718 100644
--- a/src/java/org/apache/cassandra/cql3/Cql.g
+++ b/src/java/org/apache/cassandra/cql3/Cql.g
@@ -362,9 +362,7 @@ createIndexStatement returns [CreateIndexStatement expr]
alterTableStatement returns [AlterTableStatement expr]
@init {
AlterTableStatement.Type type = null;
-String validator = null;
-ColumnIdentifier columnName = null;
-MapString, String propertyMap = null;
+props = new HashMapString, String();
}
: K_ALTER K_COLUMNFAMILY cf=columnFamilyName
( K_ALTER id=cident K_TYPE v=comparatorType { type =
AlterTableStatement.Type.ALTER; }
http://git-wip-us.apache.org/repos/asf/cassandra/blob/36a9f9bd/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
--
diff --git
a/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
index 1ecbd8a..37db2fd 100644
--- a/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
@@ -47,7 +47,7 @@ public class AlterTableStatement extends
SchemaAlteringStatement
{
super(name);
this.oType = type;
-this.columnName = null;
+this.columnName = columnName;
this.validator = validator; // used only for ADD/ALTER commands
this.cfProps.addAll(propertyMap);
}
[7/9] git commit: fix recognizing uppercase SELECT keyword patch by Jonas Dohse and pcannon for CASSANDRA-4161
fix recognizing uppercase SELECT keyword patch by Jonas Dohse and pcannon for CASSANDRA-4161 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/dc975e8a Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/dc975e8a Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/dc975e8a Branch: refs/heads/trunk Commit: dc975e8ac3c6fc557e8b2b3ad83742bd259f91ac Parents: 43a472e Author: Jonathan Ellis jbel...@apache.org Authored: Thu Apr 19 14:00:32 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Thu Apr 19 14:00:32 2012 -0500 -- CHANGES.txt |1 + bin/cqlsh |2 +- 2 files changed, 2 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/dc975e8a/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index c6fa3d3..8a9d924 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 1.1-dev + * (cqlsh) fix recognizing uppercase SELECT keyword (CASSANDRA-4161) * average a reduced liveRatio estimate with the previous one (CASSANDRA-4065) * Allow KS and CF names up to 48 characters (CASSANDRA-4157) * Add support for CL.TWO and CL.THREE in CQL (CASSANDRA-4156) http://git-wip-us.apache.org/repos/asf/cassandra/blob/dc975e8a/bin/cqlsh -- diff --git a/bin/cqlsh b/bin/cqlsh index 505b705..c26324a 100755 --- a/bin/cqlsh +++ b/bin/cqlsh @@ -804,7 +804,7 @@ class Shell(cmd.Cmd): return self.perform_statement(cqlhandling.cql_extract_orig(tokens, srcstr)) def handle_parse_error(self, cmdword, tokens, parsed, srcstr): -if cmdword == 'select': +if cmdword.lower() == 'select': # hey, maybe they know about some new syntax we don't. type # assumptions won't work, but maybe the query will. return self.perform_statement(cqlhandling.cql_extract_orig(tokens, srcstr))
[8/9] git commit: fix recognizing uppercase SELECT keyword patch by Jonas Dohse and pcannon for CASSANDRA-4161
fix recognizing uppercase SELECT keyword patch by Jonas Dohse and pcannon for CASSANDRA-4161 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/dc975e8a Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/dc975e8a Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/dc975e8a Branch: refs/heads/cassandra-1.1.0 Commit: dc975e8ac3c6fc557e8b2b3ad83742bd259f91ac Parents: 43a472e Author: Jonathan Ellis jbel...@apache.org Authored: Thu Apr 19 14:00:32 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Thu Apr 19 14:00:32 2012 -0500 -- CHANGES.txt |1 + bin/cqlsh |2 +- 2 files changed, 2 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/dc975e8a/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index c6fa3d3..8a9d924 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 1.1-dev + * (cqlsh) fix recognizing uppercase SELECT keyword (CASSANDRA-4161) * average a reduced liveRatio estimate with the previous one (CASSANDRA-4065) * Allow KS and CF names up to 48 characters (CASSANDRA-4157) * Add support for CL.TWO and CL.THREE in CQL (CASSANDRA-4156) http://git-wip-us.apache.org/repos/asf/cassandra/blob/dc975e8a/bin/cqlsh -- diff --git a/bin/cqlsh b/bin/cqlsh index 505b705..c26324a 100755 --- a/bin/cqlsh +++ b/bin/cqlsh @@ -804,7 +804,7 @@ class Shell(cmd.Cmd): return self.perform_statement(cqlhandling.cql_extract_orig(tokens, srcstr)) def handle_parse_error(self, cmdword, tokens, parsed, srcstr): -if cmdword == 'select': +if cmdword.lower() == 'select': # hey, maybe they know about some new syntax we don't. type # assumptions won't work, but maybe the query will. return self.perform_statement(cqlhandling.cql_extract_orig(tokens, srcstr))
[9/9] git commit: fix recognizing uppercase SELECT keyword patch by Jonas Dohse and pcannon for CASSANDRA-4161
fix recognizing uppercase SELECT keyword patch by Jonas Dohse and pcannon for CASSANDRA-4161 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/dc975e8a Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/dc975e8a Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/dc975e8a Branch: refs/heads/cassandra-1.1 Commit: dc975e8ac3c6fc557e8b2b3ad83742bd259f91ac Parents: 43a472e Author: Jonathan Ellis jbel...@apache.org Authored: Thu Apr 19 14:00:32 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Thu Apr 19 14:00:32 2012 -0500 -- CHANGES.txt |1 + bin/cqlsh |2 +- 2 files changed, 2 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/dc975e8a/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index c6fa3d3..8a9d924 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 1.1-dev + * (cqlsh) fix recognizing uppercase SELECT keyword (CASSANDRA-4161) * average a reduced liveRatio estimate with the previous one (CASSANDRA-4065) * Allow KS and CF names up to 48 characters (CASSANDRA-4157) * Add support for CL.TWO and CL.THREE in CQL (CASSANDRA-4156) http://git-wip-us.apache.org/repos/asf/cassandra/blob/dc975e8a/bin/cqlsh -- diff --git a/bin/cqlsh b/bin/cqlsh index 505b705..c26324a 100755 --- a/bin/cqlsh +++ b/bin/cqlsh @@ -804,7 +804,7 @@ class Shell(cmd.Cmd): return self.perform_statement(cqlhandling.cql_extract_orig(tokens, srcstr)) def handle_parse_error(self, cmdword, tokens, parsed, srcstr): -if cmdword == 'select': +if cmdword.lower() == 'select': # hey, maybe they know about some new syntax we don't. type # assumptions won't work, but maybe the query will. return self.perform_statement(cqlhandling.cql_extract_orig(tokens, srcstr))
[jira] [Commented] (CASSANDRA-4173) cqlsh: in cql3 mode, use cql3 quoting when outputting cql
[
https://issues.apache.org/jira/browse/CASSANDRA-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257813#comment-13257813
]
paul cannon commented on CASSANDRA-4173:
No, it doesn't. Definitely that would have been easier.
cqlsh: in cql3 mode, use cql3 quoting when outputting cql
-
Key: CASSANDRA-4173
URL: https://issues.apache.org/jira/browse/CASSANDRA-4173
Project: Cassandra
Issue Type: Improvement
Components: Tools
Affects Versions: 1.1.0
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
Labels: cql3, cqlsh
when cqlsh needs to output a column name or other term which needs quoting
(say, if you run DESCRIBE KEYSPACE and some column name has a space in it),
it currently only knows how to quote in the cql2 way. That is,
{noformat}
cqlsh:foo describe columnfamily bar
CREATE COLUMNFAMILY bar (
a int PRIMARY KEY,
'b c' text
) WITH
...
{noformat}
cql3 does not recognize single quotes around column names, or columnfamily or
keyspace names either. cqlsh ought to learn how to use double-quotes instead
when in cql3 mode.
--
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-4174) Unnecessary compaction happens when streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257821#comment-13257821 ] Jonathan Ellis commented on CASSANDRA-4174: --- Devil's advocate for the status quo: starting compaction as soon as I have one sstable to work on might smooth out the workload more. (If we finish the first compaction before the next is available, then great; if we don't, then they'll stack up and we'll do something closer to the all at once approach.) Thoughts? Unnecessary compaction happens when streaming - Key: CASSANDRA-4174 URL: https://issues.apache.org/jira/browse/CASSANDRA-4174 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0.0 Reporter: Yuki Morishita Assignee: Yuki Morishita Priority: Minor Fix For: 1.0.10 Attachments: 4174-1.0.txt When streaming session finishes, streamed sstabls are added to CFS one by one using ColumnFamilyStore#addSSTable(https://github.com/apache/cassandra/blob/cassandra-1.0.9/src/java/org/apache/cassandra/streaming/StreamInSession.java#L141). This method submits compaction in background(https://github.com/apache/cassandra/blob/cassandra-1.0.9/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L946), and end up with unnecessary compaction tasks behind. -- 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-4175) Reduce memory (and disk) space requirements with a column name/id map
Reduce memory (and disk) space requirements with a column name/id map - Key: CASSANDRA-4175 URL: https://issues.apache.org/jira/browse/CASSANDRA-4175 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Fix For: 1.2 We spend a lot of memory on column names, both transiently (during reads) and more permanently (in the row cache). Compression mitigates this on disk but not on the heap. The overhead is significant for typical small column values, e.g., ints. Even though we intern once we get to the memtable, this affects writes too via very high allocation rates in the young generation, hence more GC activity. Now that CQL3 provides us some guarantees that column names must be defined before they are inserted, we could create a map of (say) 32-bit int column id, to names, and use that internally right up until we return a resultset to the client. -- 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-4175) Reduce memory (and disk) space requirements with a column name/id map
[ https://issues.apache.org/jira/browse/CASSANDRA-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257836#comment-13257836 ] Jonathan Ellis commented on CASSANDRA-4175: --- The wrinkle here is concurrent schema changes -- how can we make sure each node uses the same column ids for each name? I see two possible approaches: # embed something like Zookeeper to standardize the id map # punt: let each node use a node-local map, and translate back and forth to full column name across node boundaries Reduce memory (and disk) space requirements with a column name/id map - Key: CASSANDRA-4175 URL: https://issues.apache.org/jira/browse/CASSANDRA-4175 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Fix For: 1.2 We spend a lot of memory on column names, both transiently (during reads) and more permanently (in the row cache). Compression mitigates this on disk but not on the heap. The overhead is significant for typical small column values, e.g., ints. Even though we intern once we get to the memtable, this affects writes too via very high allocation rates in the young generation, hence more GC activity. Now that CQL3 provides us some guarantees that column names must be defined before they are inserted, we could create a map of (say) 32-bit int column id, to names, and use that internally right up until we return a resultset to the client. -- 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-4052) Add way to force the cassandra-cli to refresh it's schema
[ https://issues.apache.org/jira/browse/CASSANDRA-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4052: -- Reviewer: xedin Fix Version/s: 1.1.1 Assignee: Dave Brosius Labels: cli (was: ) bq. To retain assume commands that have been applied, hold assumptions in a separate class that holds a map of these assumptions. Since we now have that, save these assumptions across separate invocations of cli by storing in a ~/.cassandra-cli directory file. Nice! Add way to force the cassandra-cli to refresh it's schema - Key: CASSANDRA-4052 URL: https://issues.apache.org/jira/browse/CASSANDRA-4052 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Tupshin Harper Assignee: Dave Brosius Priority: Minor Labels: cli Fix For: 1.1.1 Attachments: 4052_refresh_schema.diff By design, the cassandra-cli caches the schema and doesn't refresh it when various commands like describe keyspaces are run. This is reasonable, and it is easy enough to restart the cli if necessary. However, this does lead to confusion since a new user can reasonably assume that describe keyspaces will always show an accurate current represention of the ring. We should find a way to reduce the surprise (and lack of easy discoverability) of this behaviour. I propose any one of the following(#1 is probably the easiest and most likely): 1) Add a command (that would be documented in the cli's help) to explicitly refresh the schema (schema refresh, refresh schema, or anything similar). 2) Always force a refresh of the schema when performing at least the describe keyspaces command. 3) Add a flag to cassandra-cli to explicitly enable schema caching. If that flag is not passed, then schema caching will be disabled for that session. This suggestion assumes that for simple deployments (few CFs, etc), schema caching isn't very important to the performance of the cli. -- 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-4174) Unnecessary compaction happens when streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257852#comment-13257852 ] Yuki Morishita commented on CASSANDRA-4174: --- bq. starting compaction as soon as I have one sstable to work on might smooth out the workload more. Current version of cassandra adds sstables and submits compaction when finished streaming all files, not when finished streaming just one file. In my laptop, I bulkloaded 72 sstables to empty, single node cassandra and triggered compaction 9 times without the patch, in contrast to 3 times with patch applied. Unnecessary compaction happens when streaming - Key: CASSANDRA-4174 URL: https://issues.apache.org/jira/browse/CASSANDRA-4174 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0.0 Reporter: Yuki Morishita Assignee: Yuki Morishita Priority: Minor Fix For: 1.0.10 Attachments: 4174-1.0.txt When streaming session finishes, streamed sstabls are added to CFS one by one using ColumnFamilyStore#addSSTable(https://github.com/apache/cassandra/blob/cassandra-1.0.9/src/java/org/apache/cassandra/streaming/StreamInSession.java#L141). This method submits compaction in background(https://github.com/apache/cassandra/blob/cassandra-1.0.9/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L946), and end up with unnecessary compaction tasks behind. -- 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-4174) Unnecessary compaction happens when streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257890#comment-13257890 ] Jonathan Ellis commented on CASSANDRA-4174: --- I see. So is this basically a cosmetic change then, to not have redundant tasks created? If so, I think I'd rather commit to 1.1.1. Unnecessary compaction happens when streaming - Key: CASSANDRA-4174 URL: https://issues.apache.org/jira/browse/CASSANDRA-4174 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0.0 Reporter: Yuki Morishita Assignee: Yuki Morishita Priority: Minor Fix For: 1.0.10 Attachments: 4174-1.0.txt When streaming session finishes, streamed sstabls are added to CFS one by one using ColumnFamilyStore#addSSTable(https://github.com/apache/cassandra/blob/cassandra-1.0.9/src/java/org/apache/cassandra/streaming/StreamInSession.java#L141). This method submits compaction in background(https://github.com/apache/cassandra/blob/cassandra-1.0.9/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L946), and end up with unnecessary compaction tasks behind. -- 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-4174) Unnecessary compaction happens when streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-4174: -- Attachment: 4174-1.1.txt I posted this issue as Improvement, so it makes sense to put this in 1.1.1. :) Patch attached for 1.1 branch. Unnecessary compaction happens when streaming - Key: CASSANDRA-4174 URL: https://issues.apache.org/jira/browse/CASSANDRA-4174 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0.0 Reporter: Yuki Morishita Assignee: Yuki Morishita Priority: Minor Fix For: 1.0.10 Attachments: 4174-1.0.txt, 4174-1.1.txt When streaming session finishes, streamed sstabls are added to CFS one by one using ColumnFamilyStore#addSSTable(https://github.com/apache/cassandra/blob/cassandra-1.0.9/src/java/org/apache/cassandra/streaming/StreamInSession.java#L141). This method submits compaction in background(https://github.com/apache/cassandra/blob/cassandra-1.0.9/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L946), and end up with unnecessary compaction tasks behind. -- 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-4175) Reduce memory (and disk) space requirements with a column name/id map
[ https://issues.apache.org/jira/browse/CASSANDRA-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257990#comment-13257990 ] T Jake Luciani commented on CASSANDRA-4175: --- Can't you use String.hashCode? it's portable. Reduce memory (and disk) space requirements with a column name/id map - Key: CASSANDRA-4175 URL: https://issues.apache.org/jira/browse/CASSANDRA-4175 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Fix For: 1.2 We spend a lot of memory on column names, both transiently (during reads) and more permanently (in the row cache). Compression mitigates this on disk but not on the heap. The overhead is significant for typical small column values, e.g., ints. Even though we intern once we get to the memtable, this affects writes too via very high allocation rates in the young generation, hence more GC activity. Now that CQL3 provides us some guarantees that column names must be defined before they are inserted, we could create a map of (say) 32-bit int column id, to names, and use that internally right up until we return a resultset to the client. -- 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-4175) Reduce memory (and disk) space requirements with a column name/id map
[ https://issues.apache.org/jira/browse/CASSANDRA-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258017#comment-13258017 ] Jonathan Ellis commented on CASSANDRA-4175: --- And extremely collision-prone. :) Reduce memory (and disk) space requirements with a column name/id map - Key: CASSANDRA-4175 URL: https://issues.apache.org/jira/browse/CASSANDRA-4175 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Fix For: 1.2 We spend a lot of memory on column names, both transiently (during reads) and more permanently (in the row cache). Compression mitigates this on disk but not on the heap. The overhead is significant for typical small column values, e.g., ints. Even though we intern once we get to the memtable, this affects writes too via very high allocation rates in the young generation, hence more GC activity. Now that CQL3 provides us some guarantees that column names must be defined before they are inserted, we could create a map of (say) 32-bit int column id, to names, and use that internally right up until we return a resultset to the client. -- 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-4175) Reduce memory (and disk) space requirements with a column name/id map
[ https://issues.apache.org/jira/browse/CASSANDRA-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258027#comment-13258027 ] Dave Brosius commented on CASSANDRA-4175: - how about System.identityHashCode(string) ? Reduce memory (and disk) space requirements with a column name/id map - Key: CASSANDRA-4175 URL: https://issues.apache.org/jira/browse/CASSANDRA-4175 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Fix For: 1.2 We spend a lot of memory on column names, both transiently (during reads) and more permanently (in the row cache). Compression mitigates this on disk but not on the heap. The overhead is significant for typical small column values, e.g., ints. Even though we intern once we get to the memtable, this affects writes too via very high allocation rates in the young generation, hence more GC activity. Now that CQL3 provides us some guarantees that column names must be defined before they are inserted, we could create a map of (say) 32-bit int column id, to names, and use that internally right up until we return a resultset to the client. -- 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-4176) Support for sharding wide rows in CQL 3.0
[
https://issues.apache.org/jira/browse/CASSANDRA-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Bailey updated CASSANDRA-4176:
---
Description:
CQL 3.0 currently has support for defining wide rows by declaring a composite
primary key. For example:
{noformat}
CREATE TABLE timeline (
user_id varchar,
tweet_id uuid,
author varchar,
body varchar,
PRIMARY KEY (user_id, tweet_id)
);
{noformat}
It would also be useful to manage sharding a wide row through the cql schema.
This would require being able to split up the actual row key in the schema
definition. In the above example you might want to make the row key a
combination of user_id and day_of_tweet, in order to shard timelines by day.
This might look something like:
{noformat}
CREATE TABLE timeline (
user_id varchar,
day_of_tweet date,
tweet_id uuid,
author varchar,
body varchar,
PRIMARY KEY (user_id REQUIRED, day_of_tweet REQUIRED, tweet_id)
);
{noformat}
Thats probably a terrible attempt at how to structure that in CQL. But I think
I've gotten the point across. I tagged this for cql 3.0, but I'm honestly not
sure how much work it might be. As far as I know built in support for composite
keys is limited.
was:
CQL 3.0 currently has support for defining wide rows by declaring a composite
primary key. For example:
{noformat}
CREATE TABLE timeline (
user_id varchar,
tweet_id uuid,
author varchar,
body varchar,
PRIMARY KEY (user_id, tweet_id)
);
{noformat}
It would also be useful to manage sharding a wide row through the cql schema.
This would require being able to split up the actual row key in the schema
definition. In the above example you might want to make the row key a
combination of user_id and day_of_tweet, on order to shard timelines by day.
This might look something like:
{noformat}
CREATE TABLE timeline (
user_id varchar,
day_of_tweet date,
tweet_id uuid,
author varchar,
body varchar,
PRIMARY KEY (user_id REQUIRED, day_of_tweet REQUIRED, tweet_id)
);
{noformat}
Thats probably a terrible attempt at how to structure that in CQL. But I think
I've gotten the point across. I tagged this for cql 3.0, but I'm honestly not
sure how much work it might be. As far as I know built in support for composite
keys is limited.
Support for sharding wide rows in CQL 3.0
-
Key: CASSANDRA-4176
URL: https://issues.apache.org/jira/browse/CASSANDRA-4176
Project: Cassandra
Issue Type: Sub-task
Components: API
Reporter: Nick Bailey
Fix For: 1.1.1
CQL 3.0 currently has support for defining wide rows by declaring a composite
primary key. For example:
{noformat}
CREATE TABLE timeline (
user_id varchar,
tweet_id uuid,
author varchar,
body varchar,
PRIMARY KEY (user_id, tweet_id)
);
{noformat}
It would also be useful to manage sharding a wide row through the cql schema.
This would require being able to split up the actual row key in the schema
definition. In the above example you might want to make the row key a
combination of user_id and day_of_tweet, in order to shard timelines by day.
This might look something like:
{noformat}
CREATE TABLE timeline (
user_id varchar,
day_of_tweet date,
tweet_id uuid,
author varchar,
body varchar,
PRIMARY KEY (user_id REQUIRED, day_of_tweet REQUIRED, tweet_id)
);
{noformat}
Thats probably a terrible attempt at how to structure that in CQL. But I
think I've gotten the point across. I tagged this for cql 3.0, but I'm
honestly not sure how much work it might be. As far as I know built in
support for composite keys is limited.
--
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-4176) Support for sharding wide rows in CQL 3.0
Support for sharding wide rows in CQL 3.0
-
Key: CASSANDRA-4176
URL: https://issues.apache.org/jira/browse/CASSANDRA-4176
Project: Cassandra
Issue Type: Sub-task
Components: API
Reporter: Nick Bailey
CQL 3.0 currently has support for defining wide rows by declaring a composite
primary key. For example:
{noformat}
CREATE TABLE timeline (
user_id varchar,
tweet_id uuid,
author varchar,
body varchar,
PRIMARY KEY (user_id, tweet_id)
);
{noformat}
It would also be useful to manage sharding a wide row through the cql schema.
This would require being able to split up the actual row key in the schema
definition. In the above example you might want to make the row key a
combination of user_id and day_of_tweet, on order to shard timelines by day.
This might look something like:
{noformat}
CREATE TABLE timeline (
user_id varchar,
day_of_tweet date,
tweet_id uuid,
author varchar,
body varchar,
PRIMARY KEY (user_id REQUIRED, day_of_tweet REQUIRED, tweet_id)
);
{noformat}
Thats probably a terrible attempt at how to structure that in CQL. But I think
I've gotten the point across. I tagged this for cql 3.0, but I'm honestly not
sure how much work it might be. As far as I know built in support for composite
keys is limited.
--
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-4175) Reduce memory (and disk) space requirements with a column name/id map
[ https://issues.apache.org/jira/browse/CASSANDRA-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258030#comment-13258030 ] Jonathan Ellis commented on CASSANDRA-4175: --- Hashcode just isn't designed to be collision-resistant; it prioritizes speed. Even with a better (from the standpoint of collisions) general-purpose hash like Murmur, 32bits is just too small. The smallest cryptographic hash I know of is md5, and ballooning to 128bits puts a serious crimp in the potential savings here. Reduce memory (and disk) space requirements with a column name/id map - Key: CASSANDRA-4175 URL: https://issues.apache.org/jira/browse/CASSANDRA-4175 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Fix For: 1.2 We spend a lot of memory on column names, both transiently (during reads) and more permanently (in the row cache). Compression mitigates this on disk but not on the heap. The overhead is significant for typical small column values, e.g., ints. Even though we intern once we get to the memtable, this affects writes too via very high allocation rates in the young generation, hence more GC activity. Now that CQL3 provides us some guarantees that column names must be defined before they are inserted, we could create a map of (say) 32-bit int column id, to names, and use that internally right up until we return a resultset to the client. -- 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] [Issue Comment Edited] (CASSANDRA-4175) Reduce memory (and disk) space requirements with a column name/id map
[ https://issues.apache.org/jira/browse/CASSANDRA-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258030#comment-13258030 ] Jonathan Ellis edited comment on CASSANDRA-4175 at 4/20/12 5:34 AM: identityHashCode is basically the object's location in memory, so it's not going to be the same on different nodes. (So it would work for approach 2, I suppose, but I'd rather use a simple int counter.) was (Author: jbellis): Hashcode just isn't designed to be collision-resistant; it prioritizes speed. Even with a better (from the standpoint of collisions) general-purpose hash like Murmur, 32bits is just too small. The smallest cryptographic hash I know of is md5, and ballooning to 128bits puts a serious crimp in the potential savings here. Reduce memory (and disk) space requirements with a column name/id map - Key: CASSANDRA-4175 URL: https://issues.apache.org/jira/browse/CASSANDRA-4175 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Fix For: 1.2 We spend a lot of memory on column names, both transiently (during reads) and more permanently (in the row cache). Compression mitigates this on disk but not on the heap. The overhead is significant for typical small column values, e.g., ints. Even though we intern once we get to the memtable, this affects writes too via very high allocation rates in the young generation, hence more GC activity. Now that CQL3 provides us some guarantees that column names must be defined before they are inserted, we could create a map of (say) 32-bit int column id, to names, and use that internally right up until we return a resultset to the client. -- 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
