[jira] [Created] (CASSANDRA-7298) manupilation
marwa created CASSANDRA-7298: - Summary: manupilation Key: CASSANDRA-7298 URL: https://issues.apache.org/jira/browse/CASSANDRA-7298 Project: Cassandra Issue Type: Bug Components: Config, Drivers (now out of tree) Reporter: marwa Fix For: 2.0.7 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7274) Better display table organization on desc table via primary key list
[
https://issues.apache.org/jira/browse/CASSANDRA-7274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14008236#comment-14008236
]
Aleksey Yeschenko commented on CASSANDRA-7274:
--
[~pmcfadin] you should just get rid of the if len(..) statement there and make
the first branch unconditional
> Better display table organization on desc table via primary key list
>
>
> Key: CASSANDRA-7274
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7274
> Project: Cassandra
> Issue Type: Improvement
>Reporter: G Gordon Worley III
>Assignee: Patrick McFadin
> Fix For: 2.0.8
>
> Attachments: 7274.txt
>
>
> In cqlsh, the desc table command does not make it sufficiently clear which
> columns are part of the row key and which are clustering keys.
> A simple change to the primary key list, though, would make it easier to tell.
> Consider the following table definition:
> {code}
> create table my_table {
> first_column text,
> second_column text,
> third_column text,
> primary key (first_column, second_column, third_column)
> }
> {code}
> This table has a row key of first_column and clustering keys of
> second_column, third_column. But if the user intended for the table to have
> all three in the row key, the correct definition would be:
> {code}
> create table my_table {
> first_column text,
> second_column text,
> third_column text,
> primary key ((first_column, second_column, third_column))
> }
> {code}
> But this is a sufficiently subtle difference that the first may be mistaken
> for the second or vice-versa.
> My suggested solution is to always wrap the row key in parentheses. This is
> already supported by create table syntax, so it's just a matter of changing
> desc table to display the create table statement with the primary key always
> in parentheses, like so:
> {code}
> create table my_table {
> first_column text,
> second_column text,
> third_column text,
> primary key ((first_column), second_column, third_column)
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CASSANDRA-7297) semi-immutable CQL rows
Tupshin Harper created CASSANDRA-7297: - Summary: semi-immutable CQL rows Key: CASSANDRA-7297 URL: https://issues.apache.org/jira/browse/CASSANDRA-7297 Project: Cassandra Issue Type: Improvement Components: API, Core Reporter: Tupshin Harper There are many use cases, where data is immutable at the domain model level. Most time-series/audit trail/logging applications fit this approach. A relatively simple way to implement a bare-bones version of this would be to have a table-level schema option for "first writer wins", so that in the event of any conflict, the more recent version would be thrown on the floor. Obviously, this is not failure proof in the face of inconsistent timestamps, but that is a problem to be addressed outside of Cassandra. Optional additional features could include logging any non-identical cells discarded due to collision. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7296) Add CL.COORDINATOR_ONLY
Tupshin Harper created CASSANDRA-7296: - Summary: Add CL.COORDINATOR_ONLY Key: CASSANDRA-7296 URL: https://issues.apache.org/jira/browse/CASSANDRA-7296 Project: Cassandra Issue Type: Improvement Reporter: Tupshin Harper For reasons such as CASSANDRA-6340 and similar, it would be nice to have a read that never gets distributed, and only works if the coordinator you are talking to is an owner of the row. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-5394) Allow assigning disk quotas by keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14008189#comment-14008189 ] Tupshin Harper commented on CASSANDRA-5394: --- Grouping together multitenant feature requests. There might be a "soft cap" approach to make this one viable. > Allow assigning disk quotas by keyspace > --- > > Key: CASSANDRA-5394 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5394 > Project: Cassandra > Issue Type: New Feature >Reporter: J.B. Langston >Assignee: Tupshin Harper >Priority: Minor > > A customer is requesting this. They are implementing a multi-tenant Cassandra > Service offering. They want to limit the amount of diskspace that a user or > application can consume. They would also want to be able to modify the quota > after the keyspace is set up. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CASSANDRA-5394) Allow assigning disk quotas by keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tupshin Harper reassigned CASSANDRA-5394: - Assignee: Tupshin Harper > Allow assigning disk quotas by keyspace > --- > > Key: CASSANDRA-5394 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5394 > Project: Cassandra > Issue Type: New Feature >Reporter: J.B. Langston >Assignee: Tupshin Harper >Priority: Minor > > A customer is requesting this. They are implementing a multi-tenant Cassandra > Service offering. They want to limit the amount of diskspace that a user or > application can consume. They would also want to be able to modify the quota > after the keyspace is set up. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-841) Track statistics by user as well as CF
[ https://issues.apache.org/jira/browse/CASSANDRA-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14008188#comment-14008188 ] Tupshin Harper commented on CASSANDRA-841: -- Grouping together multitenant feature requests > Track statistics by user as well as CF > -- > > Key: CASSANDRA-841 > URL: https://issues.apache.org/jira/browse/CASSANDRA-841 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Jonathan Ellis >Assignee: Tupshin Harper >Priority: Minor > Fix For: 0.8 beta 1 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CASSANDRA-841) Track statistics by user as well as CF
[ https://issues.apache.org/jira/browse/CASSANDRA-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tupshin Harper reassigned CASSANDRA-841: Assignee: Tupshin Harper > Track statistics by user as well as CF > -- > > Key: CASSANDRA-841 > URL: https://issues.apache.org/jira/browse/CASSANDRA-841 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Jonathan Ellis >Assignee: Tupshin Harper >Priority: Minor > Fix For: 0.8 beta 1 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CASSANDRA-2068) Improvements for Multi-tenant clusters
[ https://issues.apache.org/jira/browse/CASSANDRA-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tupshin Harper reassigned CASSANDRA-2068: - Assignee: Tupshin Harper > Improvements for Multi-tenant clusters > -- > > Key: CASSANDRA-2068 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2068 > Project: Cassandra > Issue Type: Improvement >Reporter: Chris Goffinet >Assignee: Tupshin Harper >Priority: Minor > > It would be helpful if we could actually set some limits per CF to help > Multi-tenant clusters. Here are some ideas I was thinking: > (per CF) > 1. Set an upper bound (max) for count when slicing or multi/get calls > 2. Set an upper bound (max) for how much data in bytes can be returned > (64KB, 512KB, 1MB, etc) > This would introduce new exceptions that can be thrown. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7274) Better display table organization on desc table via primary key list
[
https://issues.apache.org/jira/browse/CASSANDRA-7274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick McFadin updated CASSANDRA-7274:
---
Attachment: 7274.txt
Simple change in cqlsh to add parenthesis around a single partition key when
doing a "DESCRIBE TABLE"
> Better display table organization on desc table via primary key list
>
>
> Key: CASSANDRA-7274
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7274
> Project: Cassandra
> Issue Type: Improvement
>Reporter: G Gordon Worley III
>Assignee: Patrick McFadin
> Fix For: 2.0.8
>
> Attachments: 7274.txt
>
>
> In cqlsh, the desc table command does not make it sufficiently clear which
> columns are part of the row key and which are clustering keys.
> A simple change to the primary key list, though, would make it easier to tell.
> Consider the following table definition:
> {code}
> create table my_table {
> first_column text,
> second_column text,
> third_column text,
> primary key (first_column, second_column, third_column)
> }
> {code}
> This table has a row key of first_column and clustering keys of
> second_column, third_column. But if the user intended for the table to have
> all three in the row key, the correct definition would be:
> {code}
> create table my_table {
> first_column text,
> second_column text,
> third_column text,
> primary key ((first_column, second_column, third_column))
> }
> {code}
> But this is a sufficiently subtle difference that the first may be mistaken
> for the second or vice-versa.
> My suggested solution is to always wrap the row key in parentheses. This is
> already supported by create table syntax, so it's just a matter of changing
> desc table to display the create table statement with the primary key always
> in parentheses, like so:
> {code}
> create table my_table {
> first_column text,
> second_column text,
> third_column text,
> primary key ((first_column), second_column, third_column)
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CASSANDRA-7274) Better display table organization on desc table via primary key list
[
https://issues.apache.org/jira/browse/CASSANDRA-7274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick McFadin reassigned CASSANDRA-7274:
--
Assignee: Patrick McFadin
> Better display table organization on desc table via primary key list
>
>
> Key: CASSANDRA-7274
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7274
> Project: Cassandra
> Issue Type: Improvement
>Reporter: G Gordon Worley III
>Assignee: Patrick McFadin
> Fix For: 2.0.8
>
>
> In cqlsh, the desc table command does not make it sufficiently clear which
> columns are part of the row key and which are clustering keys.
> A simple change to the primary key list, though, would make it easier to tell.
> Consider the following table definition:
> {code}
> create table my_table {
> first_column text,
> second_column text,
> third_column text,
> primary key (first_column, second_column, third_column)
> }
> {code}
> This table has a row key of first_column and clustering keys of
> second_column, third_column. But if the user intended for the table to have
> all three in the row key, the correct definition would be:
> {code}
> create table my_table {
> first_column text,
> second_column text,
> third_column text,
> primary key ((first_column, second_column, third_column))
> }
> {code}
> But this is a sufficiently subtle difference that the first may be mistaken
> for the second or vice-versa.
> My suggested solution is to always wrap the row key in parentheses. This is
> already supported by create table syntax, so it's just a matter of changing
> desc table to display the create table statement with the primary key always
> in parentheses, like so:
> {code}
> create table my_table {
> first_column text,
> second_column text,
> third_column text,
> primary key ((first_column), second_column, third_column)
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7274) Better display table organization on desc table via primary key list
[
https://issues.apache.org/jira/browse/CASSANDRA-7274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick McFadin updated CASSANDRA-7274:
---
Fix Version/s: 2.0.8
> Better display table organization on desc table via primary key list
>
>
> Key: CASSANDRA-7274
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7274
> Project: Cassandra
> Issue Type: Improvement
>Reporter: G Gordon Worley III
>Assignee: Patrick McFadin
> Fix For: 2.0.8
>
>
> In cqlsh, the desc table command does not make it sufficiently clear which
> columns are part of the row key and which are clustering keys.
> A simple change to the primary key list, though, would make it easier to tell.
> Consider the following table definition:
> {code}
> create table my_table {
> first_column text,
> second_column text,
> third_column text,
> primary key (first_column, second_column, third_column)
> }
> {code}
> This table has a row key of first_column and clustering keys of
> second_column, third_column. But if the user intended for the table to have
> all three in the row key, the correct definition would be:
> {code}
> create table my_table {
> first_column text,
> second_column text,
> third_column text,
> primary key ((first_column, second_column, third_column))
> }
> {code}
> But this is a sufficiently subtle difference that the first may be mistaken
> for the second or vice-versa.
> My suggested solution is to always wrap the row key in parentheses. This is
> already supported by create table syntax, so it's just a matter of changing
> desc table to display the create table statement with the primary key always
> in parentheses, like so:
> {code}
> create table my_table {
> first_column text,
> second_column text,
> third_column text,
> primary key ((first_column), second_column, third_column)
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
