[
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