[
https://issues.apache.org/jira/browse/CASSANDRA-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12916146#action_12916146
]
Sylvain Lebresne edited comment on CASSANDRA-1546 at 9/29/10 9:50 AM:
----------------------------------------------------------------------
Attaching a new version of the patch that includes the support for counter as
super columns.
I want to keep the counter-as-row too, because I believe in the marker idea a
lot and that won't
fly for counter as super columns until we don't deserialize super columns
entirely.
The details of the thrift API is a proposal, it can be discussed. In
particular, for
the batch_add call, it would have made more sense for it to take a map of
CounterPath -> CounterUpdate. However, that doesn't work in python (because
CounterPath is not hashable and thus the map can't be constructed). So it takes
something similar to batch_mutate. However, if you use batch_add to insert non
nested counters (the terminology of the patch for counter-as-row, by opposition
to
counter-as-super-columns that are called nested counters), then the first key
of the
map can be anything (which is fine but weird).
Also, the get_counter_slice and multiget_counter_slice can't be used for non
nested
counters. It won't be hard to add an equivalent of get_range_slices for
counters, but
that will have to wait.
Lastly, the implementation of batch_add sucks right now as it creates a new
mutation
for each update. Again, not hard to fix, just need some time for that.
(in an unrelated note, please tell if you prefer me to attach new versions when
I update
the patch instead of replacing them)
was (Author: slebresne):
Attaching a new version of the patch that includes the support for counter
as super columns.
I want to keep the counter-as-row too, because I believe in the marker idea a
lot and that won't
fly for counter as super columns until we don't deserialize super columns
entirely.
The details of the thrift API is a proposal, it can be discussed. In
particular, for
the batch_add call, it would have made more sense for it to take a map of
CounterPath -> CounterUpdate. However, that doesn't work in python (because
CounterPath is not hashable and thus the map can't be constructed). So it takes
something similar to batch_mutate. However, if you use batch_add to insert non
nested counters (the terminology of the patch for counter-as-row, by opposition
to
counter-as-super-columns that are called nested counters), then the first key
of the
map can be anything (which is fine but weird).
Also, the get_counter_slice and multiget_counter_slice can't be used for non
nested
counters. It won't be hard to add an equivalent of get_range_slices for
counters, but
that will have to wait.
Lastly, the implementation of batch_add sucks right now as it creates a new
mutation
for each update. Again, not hard to fix, just need some time for that.
> (Yet another) approach to counting
> ----------------------------------
>
> Key: CASSANDRA-1546
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1546
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Fix For: 0.7.0
>
> Attachments: 0001-Remove-IClock-from-internals.patch,
> 0002-Counters.patch, 0003-Generated-thrift-files-changes.patch
>
>
> This could be described as a mix between CASSANDRA-1072 without clocks and
> CASSANDRA-1421.
> More details in the comment below.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
