[jira] [Updated] (CASSANDRA-2763) When dropping a keyspace you're currently authenticated to, might be nice to de-authenticate upon completion
[ https://issues.apache.org/jira/browse/CASSANDRA-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Stein updated CASSANDRA-2763: - Attachment: 2763.txt I made the change to check we were in the keyspace we were deleting before setting it to null. This made the most sense to me putting things back in the state you are in when logging into the CLI and only when you have just deleted the keyspace you were in. When dropping a keyspace you're currently authenticated to, might be nice to de-authenticate upon completion Key: CASSANDRA-2763 URL: https://issues.apache.org/jira/browse/CASSANDRA-2763 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Jeremy Hanna Priority: Trivial Labels: cli, lhf Attachments: 2763.txt I found that when I'm authenticated to MyKeyspace, then do 'drop keyspace MyKeyspace;', I'm still authenticated to it. It's trivial I know, but seems reasonable to unauthenticate from it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2833) CounterColumn should have an optional binary field so that double can be incremented/decremented along with long
[ https://issues.apache.org/jira/browse/CASSANDRA-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056513#comment-13056513 ] Joe Stein commented on CASSANDRA-2833: -- the phrasing *not feasible* was a bit strong. In general I would argue that the up take of a system would want to have the edges smoothed out as it continued so that the flexibility of it being able to have workarounds are fantastic but as it evolved those workarounds can be internalized to the system. This burden is not always completely on the programming side but in essence the development team and having to explain to every developer that touches your system why you are multiplying by 10 and when they need to divide by 10 to get data out in the format they want. This just makes for an unclean implementation, granted functional for now with your nice workaround, by having to-do some type of naming conventions realPricing, longInventory so that folks do not incorrectly infer the wrong implementation of the counter in their own work effort. Not using double as a name anywhere is a really good point that is just going to add possible confusion. And, yes. floats are used a lot in Analytics in Mobile and Healthcare (at least two I can speak about directly) in addition to Advertising. In mobile the duration of users using application is a metric very much sought after and used and in Healthcare (as would also hold true for lots of other business verticals) when providing analyses of reimbursement between payer and provider. Most often these durations are coupled with a duration count because you do not always have 1:1 duration between uses and times you have that data though this complex type of counter I think representing as 2 columns (one long and one double) so the caller can create their average themselves which is how it is done now. What do you think about the idea to not upset existing users and support new ones with the thrift CounterColumn additional optional binary operand field? It was not my idea but I think a good one (thanks Stu Hood)? So the change could then be: 1) create a new CF RealCounterType - this would let the underlying code know to use the double instead of the long 2) change CounterColumn thrift and db accordingly so that old clients still work but new ones can use this new CF RealCounterType a) either with a optional double realvalue or b) optional binary operand 3) CounterContext seems it needs to have the support between long and double in how it wants to pass the data inside for the += in total as well as some overloading of writeElement looking at the context it seems cleaner to make the double in addition to long rather than storing it in bytes, granted this is the first time I am looking at :) or if we store it in bytes the conversion If you and others think this is a good change I am happy to start on it granted while it is probably a simple change it will take me some bumps and bruises as I go through it to get it working. And I do agree that change for the sake of change or because it is cool is never a good way to proceed which can be argued for this change, yes. But I am arguing that it is useful +1 but would like to hear from others so this change is not only for me maybe everyone else is ok the way it is CounterColumn should have an optional binary field so that double can be incremented/decremented along with long Key: CASSANDRA-2833 URL: https://issues.apache.org/jira/browse/CASSANDRA-2833 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Joe Stein Currently CounterColumn only has a long making it not feasible to track increment/decrement of durations or other values common to analytics represented as a double The change I am proposing to implement, after some discussions/advice in the irc to issues raised, is to add a new optional binary field to CounterColumn (thrift). I was thinking we could call it *operand* Under the hood (src/java/org/apache/cassandra/db/CounterColumn.java) I would handle things with byte[] moving between long and double as internal helper functions with case switch on type of operand we are setting might also need an optional enum for type perhaps too so the client can let the server know how it should materialize the bytes for when it += the value stored The clients should continue to work as expected and folks looking to use this can just do so. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2836) Add CFS.estimatedKeys to cfstats output
[
https://issues.apache.org/jira/browse/CASSANDRA-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056654#comment-13056654
]
Joe Stein commented on CASSANDRA-2836:
--
so the change looks like adding something like this
{code}
outs.println(\t\tNumber of Keys (estimate): + cfstore.estimateKeys());
{code}
maybe between
{code}
outs.println(\t\tSpace used (total): + cfstore.getTotalDiskSpaceUsed());
outs.println(\t\tNumber of Keys (estimate): + cfstore.estimateKeys());
outs.println(\t\tMemtable Columns Count: +
cfstore.getMemtableColumnsCount());
{code}
makes sense
in src/java/org/apache/cassandra/tools/NodeCmd.java
Add CFS.estimatedKeys to cfstats output
---
Key: CASSANDRA-2836
URL: https://issues.apache.org/jira/browse/CASSANDRA-2836
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Brandon Williams
Priority: Trivial
Fix For: 0.8.2
People ask for this all the time and making them resort to the hell that is
JMX is not pleasant.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2836) Add CFS.estimatedKeys to cfstats output
[ https://issues.apache.org/jira/browse/CASSANDRA-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Stein updated CASSANDRA-2836: - Attachment: 2836.txt Add CFS.estimatedKeys to cfstats output --- Key: CASSANDRA-2836 URL: https://issues.apache.org/jira/browse/CASSANDRA-2836 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brandon Williams Priority: Trivial Fix For: 0.8.2 Attachments: 2836.txt People ask for this all the time and making them resort to the hell that is JMX is not pleasant. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2833) CounterColumn should have an optional binary field so that double can be incremented/decremented along with long
CounterColumn should have an optional binary field so that double can be incremented/decremented along with long Key: CASSANDRA-2833 URL: https://issues.apache.org/jira/browse/CASSANDRA-2833 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Joe Stein Currently CounterColumn only has a long making it not feasible to track increment/decrement of durations or other values common to analytics represented as a double The change I am proposing to implement, after some discussions/advice in the irc to issues raised, is to add a new optional binary field to CounterColumn (thrift). I was thinking we could call it *operand* Under the hood (src/java/org/apache/cassandra/db/CounterColumn.java) I would handle things with byte[] moving between long and double as internal helper functions with case switch on type of operand we are setting might also need an optional enum for type perhaps too so the client can let the server know how it should materialize the bytes for when it += the value stored The clients should continue to work as expected and folks looking to use this can just do so. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
