> I agree it makes code messier
That's not a trivial point.
It isn't just about doing two queries to read. Its also having to do two
queries to write and remembering to do that in all the places.
On Wed, Nov 2, 2016 at 1:56 AM, Cody Yancey wrote:
> I agree it makes code
I agree it makes code messier, but you aren't really losing anything by
separating them out into separate tables and then doing parallel queries.
Counter tables already don't support atomic batch operations (all batch
operations are unlogged), CAS operations (LWTs not supported) and have a
whole
Here is a solution that I have leverage. Ignore the count of the value and
use a multi-part column name as it's value.
For example:
create column family stuff (
rowkey string,
column string,
value string.
counter_to_ignore long,
primary key( rowkey, column, value));
On Tue, Nov 1, 2016 at
Big Fat lol!!!
Am 01.11.2016 19:02 schrieb "Ali Akhtar" :
> ^ Stockholm syndrome :)
>
> On Tue, Nov 1, 2016 at 10:54 PM, Robert Wille wrote:
>
>> I used to think it was terrible as well. But it really isn’t. Just put
>> your non-counter columns in a
^ Stockholm syndrome :)
On Tue, Nov 1, 2016 at 10:54 PM, Robert Wille wrote:
> I used to think it was terrible as well. But it really isn’t. Just put
> your non-counter columns in a separate table with the same primary key. If
> you want to query both counter and non-counter
I used to think it was terrible as well. But it really isn’t. Just put your
non-counter columns in a separate table with the same primary key. If you want
to query both counter and non-counter columns at the same time, just query both
tables at the same time with asynchronous queries.
On Nov
That's a terrible gotcha rule.
On Tue, Nov 1, 2016 at 6:27 PM, Cody Yancey wrote:
> In your table schema, you have KEYS and you have VALUES. Your KEYS are
> text, but they could be any non-counter type or compound thereof. KEYS
> obviously cannot ever be counters.
>
> Your
In your table schema, you have KEYS and you have VALUES. Your KEYS are
text, but they could be any non-counter type or compound thereof. KEYS
obviously cannot ever be counters.
Your VALUES, however, must be either all counters or all non-counters. The
official example you posted conforms to this
I'm not referring to the primary key, just to other columns.
My primary key is a text, and my table contains a mix of texts, ints, and
timestamps.
If I try to change one of the ints to a counter and run the create table
query, I get the error ' Cannot mix counter and non counter columns in the
For counter tables, non-counter types are of course allowed in the primary
key. Counters would be meaningless otherwise.
Thanks,
Cody
On Nov 1, 2016 7:00 AM, "Ali Akhtar" wrote:
> In the documentation for counters:
>
>
10 matches
Mail list logo