cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Shaw (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-2833) CounterColumn should have an optional binary field so that double can be incremented/decremented along with long
Date Tue, 28 Jun 2011 14:09:17 GMT

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

Rick Shaw commented on CASSANDRA-2833:
--------------------------------------

A wrinkle that might be worth consideration is that the JDBC driver will eventually need an
{{AbstractType}} implementation of {{BigDecimal}} ({{NumericType}}?) in order to complete
it data type support in {{PreparedStatement}} and {{ResultSet}}.

This data type represents arbitrary-precision signed decimal numbers in a generalized way.
It has attributes similar to {{BigInteger}} ({{IntegerType}}) It is really a {{BigInteger}}
representing the unscaled part with a long representing the scaling.

This may be a better alternative than Double as a generalized counter type targeted at analytics
data.

> 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

        

Mime
View raw message