[jira] [Updated] (CASSANDRA-12954) system_distributed.view_build_status uses gc_gs of 0, but issues distributed deletes

[Jeff Jirsa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Jirsa updated CASSANDRA-12954:
---
Status: Patch Available  (was: Open)

> system_distributed.view_build_status uses gc_gs of 0, but issues distributed 
> deletes
> 
>
> Key: CASSANDRA-12954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12954
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Aleksey Yeschenko
>Assignee: Jeff Jirsa
>Priority: Trivial
>  Labels: lhf
> Fix For: 3.x
>
>
> The definition uses {{CFMetaData.compile()}} method, intended for 
> non-replicated system-keyspace tables, and doesn't override gc_grace_seconds 
> from 0, but does issue deletes. This can lead to entries in the table not 
> being cleaned up.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12954) system_distributed.view_build_status uses gc_gs of 0, but issues distributed deletes

[Jeff Jirsa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Jirsa updated CASSANDRA-12954:
---
Labels: lhf  (was: )

> system_distributed.view_build_status uses gc_gs of 0, but issues distributed 
> deletes
> 
>
> Key: CASSANDRA-12954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12954
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Aleksey Yeschenko
>Assignee: Jeff Jirsa
>Priority: Trivial
>  Labels: lhf
> Fix For: 3.x
>
>
> The definition uses {{CFMetaData.compile()}} method, intended for 
> non-replicated system-keyspace tables, and doesn't override gc_grace_seconds 
> from 0, but does issue deletes. This can lead to entries in the table not 
> being cleaned up.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12954) system_distributed.view_build_status uses gc_gs of 0, but issues distributed deletes

[Jeff Jirsa (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15719328#comment-15719328
 ] 

Jeff Jirsa commented on CASSANDRA-12954:


Adding to all tables in {{system_distributed}} - we may not automatically 
deleted from repair_history or parent_repair_history, but they're replicated, 
so if a user issues deletes, it should get a proper gcgs to be safe.

CI pending, should be ready tomorrow:

|[3.X|https://github.com/jeffjirsa/cassandra/tree/cassandra-12954-3.X] | 
[testall|http://cassci.datastax.com/job/jeffjirsa-cassandra-12954-3.X-testall/] 
| [dtest|http://cassci.datastax.com/job/jeffjirsa-cassandra-12954-3.X-dtest/]|
|[trunk|https://github.com/jeffjirsa/cassandra/tree/cassandra-12954] | 
[testall|http://cassci.datastax.com/job/jeffjirsa-cassandra-12954-testall/] | 
[dtest|http://cassci.datastax.com/job/jeffjirsa-cassandra-12954-dtest/]|


> system_distributed.view_build_status uses gc_gs of 0, but issues distributed 
> deletes
> 
>
> Key: CASSANDRA-12954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12954
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Aleksey Yeschenko
>Assignee: Jeff Jirsa
>Priority: Trivial
> Fix For: 3.x
>
>
> The definition uses {{CFMetaData.compile()}} method, intended for 
> non-replicated system-keyspace tables, and doesn't override gc_grace_seconds 
> from 0, but does issue deletes. This can lead to entries in the table not 
> being cleaned up.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CASSANDRA-12954) system_distributed.view_build_status uses gc_gs of 0, but issues distributed deletes

[Jeff Jirsa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Jirsa reassigned CASSANDRA-12954:
--

Assignee: Jeff Jirsa

> system_distributed.view_build_status uses gc_gs of 0, but issues distributed 
> deletes
> 
>
> Key: CASSANDRA-12954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12954
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Aleksey Yeschenko
>Assignee: Jeff Jirsa
>Priority: Trivial
> Fix For: 3.x
>
>
> The definition uses {{CFMetaData.compile()}} method, intended for 
> non-replicated system-keyspace tables, and doesn't override gc_grace_seconds 
> from 0, but does issue deletes. This can lead to entries in the table not 
> being cleaned up.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12990) More fixes to the TokenAllocator

[Dikang Gu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dikang Gu updated CASSANDRA-12990:
--
Status: Patch Available  (was: Open)

The patch based on trunk:

|[patch | 
https://github.com/DikangGu/cassandra/commit/d986e89b7b21b5464bd1de7908ee5cb1d12dfd30]|[unit
 test | 
https://cassci.datastax.com/view/Dev/view/DikangGu/job/DikangGu-CASSANDRA-12990-trunk-testall/]|[dtest
 | 
https://cassci.datastax.com/view/Dev/view/DikangGu/job/DikangGu-CASSANDRA-12990-trunk-dtest/]|

> More fixes to the TokenAllocator
> 
>
> Key: CASSANDRA-12990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12990
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Dikang Gu
> Fix For: 3.12
>
>
> CASSANDRA-12983 fixes the NoReplicationTokenAllocator in the replication 
> factor equals 0 case.
> We find one more problem that, in our big cluster, ~1000 nodes, the Gossip 
> takes longer time to settle down, so the TokenAllocator may throw NPE when 
> trying to find the dc rack information from the Gossip metadata, in the 
> getStrategy function.
> This patch will fix it, it does two things:
> 1. wait gossip to settle down before trying to allocating tokens.
> 2. for replication factor equals 0 or 1 case, we do not need to check the 
> topology for rack information, since each node will be treated separately. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-12990) More fixes to the TokenAllocator

[Dikang Gu (JIRA)]

Dikang Gu created CASSANDRA-12990:
-

 Summary: More fixes to the TokenAllocator
 Key: CASSANDRA-12990
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12990
 Project: Cassandra
  Issue Type: Bug
Reporter: Dikang Gu
Assignee: Dikang Gu
 Fix For: 3.12


CASSANDRA-12983 fixes the NoReplicationTokenAllocator in the replication factor 
equals 0 case.

We find one more problem that, in our big cluster, ~1000 nodes, the Gossip 
takes longer time to settle down, so the TokenAllocator may throw NPE when 
trying to find the dc rack information from the Gossip metadata, in the 
getStrategy function.

This patch will fix it, it does two things:
1. wait gossip to settle down before trying to allocating tokens.
2. for replication factor equals 0 or 1 case, we do not need to check the 
topology for rack information, since each node will be treated separately. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10271) ORDER BY should allow skipping equality-restricted clustering columns

[Brett Snyder (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-10271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15718491#comment-15718491
 ] 

Brett Snyder commented on CASSANDRA-10271:
--

No, I just got sidetracked from getting back at it until today.  Attached is a 
new patch for 3.x.  Let me know what other modifications it may need.  It now 
supports the other query patterns you and Tyler mentioned earlier in the thread.

I do get one test failure after making the changes in the other existing unit 
tests in SelectOrderByTest.

java.lang.AssertionError: Query should be invalid but no error was thrown. 
Query is: SELECT v FROM %s WHERE k = 0 ORDER BY k DESC (values: [])

Wasn't sure if that condition should be removed or if my changes go a bit too 
far and are not restrictive enough to prevent that.

Thanks!

> ORDER BY should allow skipping equality-restricted clustering columns
> -
>
> Key: CASSANDRA-10271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10271
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Tyler Hobbs
>Assignee: Brett Snyder
>Priority: Minor
> Fix For: 3.x
>
> Attachments: 10271-3.x.txt, cassandra-2.2-10271.txt
>
>
> Given a table like the following:
> {noformat}
> CREATE TABLE foo (a int, b int, c int, d int, PRIMARY KEY (a, b, c));
> {noformat}
> We should support a query like this:
> {noformat}
> SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY c ASC;
> {noformat}
> Currently, this results in the following error:
> {noformat}
> [Invalid query] message="Order by currently only support the ordering of 
> columns following their declared order in the PRIMARY KEY"
> {noformat}
> However, since {{b}} is restricted by an equality restriction, we shouldn't 
> require it to be present in the {{ORDER BY}} clause.
> As a workaround, you can use this query instead:
> {noformat}
> SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY b ASC, c ASC;
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10271) ORDER BY should allow skipping equality-restricted clustering columns

[Brett Snyder (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-10271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15718492#comment-15718492
 ] 

Brett Snyder commented on CASSANDRA-10271:
--

No, I just got sidetracked from getting back at it until today.  Attached is a 
new patch for 3.x.  Let me know what other modifications it may need.  It now 
supports the other query patterns you and Tyler mentioned earlier in the thread.

I do get one test failure after making the changes in the other existing unit 
tests in SelectOrderByTest.

java.lang.AssertionError: Query should be invalid but no error was thrown. 
Query is: SELECT v FROM %s WHERE k = 0 ORDER BY k DESC (values: [])

Wasn't sure if that condition should be removed or if my changes go a bit too 
far and are not restrictive enough to prevent that.

Thanks!

> ORDER BY should allow skipping equality-restricted clustering columns
> -
>
> Key: CASSANDRA-10271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10271
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Tyler Hobbs
>Assignee: Brett Snyder
>Priority: Minor
> Fix For: 3.x
>
> Attachments: 10271-3.x.txt, cassandra-2.2-10271.txt
>
>
> Given a table like the following:
> {noformat}
> CREATE TABLE foo (a int, b int, c int, d int, PRIMARY KEY (a, b, c));
> {noformat}
> We should support a query like this:
> {noformat}
> SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY c ASC;
> {noformat}
> Currently, this results in the following error:
> {noformat}
> [Invalid query] message="Order by currently only support the ordering of 
> columns following their declared order in the PRIMARY KEY"
> {noformat}
> However, since {{b}} is restricted by an equality restriction, we shouldn't 
> require it to be present in the {{ORDER BY}} clause.
> As a workaround, you can use this query instead:
> {noformat}
> SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY b ASC, c ASC;
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-10271) ORDER BY should allow skipping equality-restricted clustering columns

[Brett Snyder (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-10271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Snyder updated CASSANDRA-10271:
-
Attachment: 10271-3.x.txt

New patch against 3.x

> ORDER BY should allow skipping equality-restricted clustering columns
> -
>
> Key: CASSANDRA-10271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10271
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Tyler Hobbs
>Assignee: Brett Snyder
>Priority: Minor
> Fix For: 3.x
>
> Attachments: 10271-3.x.txt, cassandra-2.2-10271.txt
>
>
> Given a table like the following:
> {noformat}
> CREATE TABLE foo (a int, b int, c int, d int, PRIMARY KEY (a, b, c));
> {noformat}
> We should support a query like this:
> {noformat}
> SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY c ASC;
> {noformat}
> Currently, this results in the following error:
> {noformat}
> [Invalid query] message="Order by currently only support the ordering of 
> columns following their declared order in the PRIMARY KEY"
> {noformat}
> However, since {{b}} is restricted by an equality restriction, we shouldn't 
> require it to be present in the {{ORDER BY}} clause.
> As a workaround, you can use this query instead:
> {noformat}
> SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY b ASC, c ASC;
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-10271) ORDER BY should allow skipping equality-restricted clustering columns

[Brett Snyder (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-10271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Snyder updated CASSANDRA-10271:
-
Status: Patch Available  (was: Open)

> ORDER BY should allow skipping equality-restricted clustering columns
> -
>
> Key: CASSANDRA-10271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10271
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Tyler Hobbs
>Assignee: Brett Snyder
>Priority: Minor
> Fix For: 3.x
>
> Attachments: 10271-3.x.txt, cassandra-2.2-10271.txt
>
>
> Given a table like the following:
> {noformat}
> CREATE TABLE foo (a int, b int, c int, d int, PRIMARY KEY (a, b, c));
> {noformat}
> We should support a query like this:
> {noformat}
> SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY c ASC;
> {noformat}
> Currently, this results in the following error:
> {noformat}
> [Invalid query] message="Order by currently only support the ordering of 
> columns following their declared order in the PRIMARY KEY"
> {noformat}
> However, since {{b}} is restricted by an equality restriction, we shouldn't 
> require it to be present in the {{ORDER BY}} clause.
> As a workaround, you can use this query instead:
> {noformat}
> SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY b ASC, c ASC;
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12989) Correct function doc to clear up statement isolation

[Jeff Jirsa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Jirsa updated CASSANDRA-12989:
---
Component/s: Documentation and Website

> Correct function doc to clear up statement isolation
> 
>
> Key: CASSANDRA-12989
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12989
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
> Fix For: 3.10
>
>
> Documentation arguably implies that 'now()' returns 'a unique' result 'per 
> statement'. This is not true it returns a unique result per call. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12989) Correct function doc to clear up statement isolation

[Jeff Jirsa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Jirsa updated CASSANDRA-12989:
---
Fix Version/s: 3.10

> Correct function doc to clear up statement isolation
> 
>
> Key: CASSANDRA-12989
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12989
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
> Fix For: 3.10
>
>
> Documentation arguably implies that 'now()' returns 'a unique' result 'per 
> statement'. This is not true it returns a unique result per call. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12989) Correct function doc to clear up statement isolation

[Jeff Jirsa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Jirsa updated CASSANDRA-12989:
---
Resolution: Fixed
  Reviewer: Jeff Jirsa
Status: Resolved  (was: Patch Available)

Thanks [~appodictic]. Committed as {{d10d5caa3dcefb2efe1fdb6b671e1c27365176cb}}



> Correct function doc to clear up statement isolation
> 
>
> Key: CASSANDRA-12989
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12989
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>
> Documentation arguably implies that 'now()' returns 'a unique' result 'per 
> statement'. This is not true it returns a unique result per call. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

cassandra git commit: CASSANDRA-12989: Fix documentation for now()

[jjirsa]

Repository: cassandra
Updated Branches:
  refs/heads/trunk adbb7ec4d -> d10d5caa3


CASSANDRA-12989: Fix documentation for now()

Patch by  Edward Capriolo; Reviewed by Jeff Jirsa for CASSANDRA-12989


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d10d5caa
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d10d5caa
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d10d5caa

Branch: refs/heads/trunk
Commit: d10d5caa3dcefb2efe1fdb6b671e1c27365176cb
Parents: adbb7ec
Author: Edward Capriolo 
Authored: Sat Dec 3 11:41:04 2016 -0500
Committer: Jeff Jirsa 
Committed: Sat Dec 3 09:33:02 2016 -0800

--
 doc/source/cql/functions.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/d10d5caa/doc/source/cql/functions.rst
--
diff --git a/doc/source/cql/functions.rst b/doc/source/cql/functions.rst
index 47026cd..6ae7cbf 100644
--- a/doc/source/cql/functions.rst
+++ b/doc/source/cql/functions.rst
@@ -135,8 +135,8 @@ Timeuuid functions
 ``now``
 ###
 
-The ``now`` function takes no arguments and generates, on the coordinator 
node, a new unique timeuuid (at the time where
-the statement using it is executed). Note that this method is useful for 
insertion but is largely non-sensical in
+The ``now`` function takes no arguments and generates, on the coordinator 
node, a new unique timeuuid at the 
+time the function is invoked. Note that this method is useful for insertion 
but is largely non-sensical in
 ``WHERE`` clauses. For instance, a query of the form::
 
 SELECT * FROM myTable WHERE t = now()

[jira] [Updated] (CASSANDRA-10271) ORDER BY should allow skipping equality-restricted clustering columns

[Brett Snyder (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-10271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Snyder updated CASSANDRA-10271:
-
Fix Version/s: (was: 2.2.x)

> ORDER BY should allow skipping equality-restricted clustering columns
> -
>
> Key: CASSANDRA-10271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10271
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Tyler Hobbs
>Assignee: Brett Snyder
>Priority: Minor
> Fix For: 3.x
>
> Attachments: cassandra-2.2-10271.txt
>
>
> Given a table like the following:
> {noformat}
> CREATE TABLE foo (a int, b int, c int, d int, PRIMARY KEY (a, b, c));
> {noformat}
> We should support a query like this:
> {noformat}
> SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY c ASC;
> {noformat}
> Currently, this results in the following error:
> {noformat}
> [Invalid query] message="Order by currently only support the ordering of 
> columns following their declared order in the PRIMARY KEY"
> {noformat}
> However, since {{b}} is restricted by an equality restriction, we shouldn't 
> require it to be present in the {{ORDER BY}} clause.
> As a workaround, you can use this query instead:
> {noformat}
> SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY b ASC, c ASC;
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12989) Correct function doc to clear up statement isolation

[Edward Capriolo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Edward Capriolo updated CASSANDRA-12989:

Status: Patch Available  (was: Open)

> Correct function doc to clear up statement isolation
> 
>
> Key: CASSANDRA-12989
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12989
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>
> Documentation arguably implies that 'now()' returns 'a unique' result 'per 
> statement'. This is not true it returns a unique result per call. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12989) Correct function doc to clear up statement isolation

[Edward Capriolo (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15718365#comment-15718365
 ] 

Edward Capriolo commented on CASSANDRA-12989:
-

https://github.com/apache/cassandra/compare/trunk...edwardcapriolo:CASSANDRA-12989?expand=1

> Correct function doc to clear up statement isolation
> 
>
> Key: CASSANDRA-12989
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12989
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>
> Documentation arguably implies that 'now()' returns 'a unique' result 'per 
> statement'. This is not true it returns a unique result per call. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-12989) Correct function doc to clear up statement isolation

[Edward Capriolo (JIRA)]

Edward Capriolo created CASSANDRA-12989:
---

 Summary: Correct function doc to clear up statement isolation
 Key: CASSANDRA-12989
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12989
 Project: Cassandra
  Issue Type: Improvement
Reporter: Edward Capriolo
Assignee: Edward Capriolo


Documentation arguably implies that 'now()' returns 'a unique' result 'per 
statement'. This is not true it returns a unique result per call. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-7306) Support "edge dcs" with more flexible gossip

[Jeff Jirsa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Jirsa updated CASSANDRA-7306:
--
Status: Open  (was: Awaiting Feedback)

> Support "edge dcs" with more flexible gossip
> 
>
> Key: CASSANDRA-7306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7306
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Distributed Metadata
>Reporter: Tupshin Harper
>  Labels: ponies
>
> As Cassandra clusters get bigger and bigger, and their topology becomes more 
> complex, there is more and more need for a notion of "hub" and "spoke" 
> datacenters.
> One of the big obstacles to supporting hundreds (or thousands) of remote dcs, 
> is the assumption that all dcs need to talk to each other (and be connected 
> all the time).
> This ticket is a vague placeholder with the goals of achieving:
> 1) better behavioral support for occasionally disconnected datacenters
> 2) explicit support for custom dc to dc routing. A simple approach would be 
> an optional per-dc annotation of which other DCs that DC could gossip with.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-7306) Support "edge dcs" with more flexible gossip

[Jeff Jirsa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Jirsa updated CASSANDRA-7306:
--
Assignee: (was: Jeff Jirsa)

> Support "edge dcs" with more flexible gossip
> 
>
> Key: CASSANDRA-7306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7306
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Distributed Metadata
>Reporter: Tupshin Harper
>  Labels: ponies
>
> As Cassandra clusters get bigger and bigger, and their topology becomes more 
> complex, there is more and more need for a notion of "hub" and "spoke" 
> datacenters.
> One of the big obstacles to supporting hundreds (or thousands) of remote dcs, 
> is the assumption that all dcs need to talk to each other (and be connected 
> all the time).
> This ticket is a vague placeholder with the goals of achieving:
> 1) better behavioral support for occasionally disconnected datacenters
> 2) explicit support for custom dc to dc routing. A simple approach would be 
> an optional per-dc annotation of which other DCs that DC could gossip with.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)