Cassandra
  1. Cassandra
  2. CASSANDRA-2614

create Column and CounterColumn in the same column family

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Fix Version/s: None
    • Component/s: Core
    • Labels:
      None

      Description

      create Column and CounterColumn in the same column family

        Activity

        Hide
        Jonathan Ellis added a comment -

        There's so many special cases around counters (streaming, compaction, I think repair, ...) that I don't think this is feasible.

        Show
        Jonathan Ellis added a comment - There's so many special cases around counters (streaming, compaction, I think repair, ...) that I don't think this is feasible.
        Hide
        Sylvain Lebresne added a comment -

        Now that CQL allows for user side timestamp (which it should, no question asked), that row deletion problem covers CQL too (actually no yet, because of CASSANDRA-2912, but that's just a bug).

        Is it possible (when Deleting, inside a thrift Mutation) to loop through all the columns that need to be deleted

        That doesn't really help. The problem is with full row deletion. If you have a row with "regular" columns and with one declared counter column 'c1', then if you get a row deletion, you can insert a deletion with server side generated timestamp for 'c1', but what for the rest of the row ? If you insert the row tombstone, it will still screw up c1.

        One possible solution I see would be to have specific row tombstones that only act on regular columns and others that only act on counter columns. Row deletion would then adds both kind of tombstone with the right timestamp each time. But we're talking internal format change, so that would postpone this to 1.0 at best (considering we want to do it).

        Until that, we still have the possibility to disallow row deletion on mixed regular/counter column family.

        Show
        Sylvain Lebresne added a comment - Now that CQL allows for user side timestamp (which it should, no question asked), that row deletion problem covers CQL too (actually no yet, because of CASSANDRA-2912 , but that's just a bug). Is it possible (when Deleting, inside a thrift Mutation) to loop through all the columns that need to be deleted That doesn't really help. The problem is with full row deletion. If you have a row with "regular" columns and with one declared counter column 'c1', then if you get a row deletion, you can insert a deletion with server side generated timestamp for 'c1', but what for the rest of the row ? If you insert the row tombstone, it will still screw up c1. One possible solution I see would be to have specific row tombstones that only act on regular columns and others that only act on counter columns. Row deletion would then adds both kind of tombstone with the right timestamp each time. But we're talking internal format change, so that would postpone this to 1.0 at best (considering we want to do it). Until that, we still have the possibility to disallow row deletion on mixed regular/counter column family.
        Hide
        Dave Rav added a comment - - edited

        Is it possible (when Deleting, inside a thrift Mutation) to loop through all
        the columns that need to be deleted
        find there type, 'validation_class' (regular or CounterColumnType)
        and delete them base on there type?

        Show
        Dave Rav added a comment - - edited Is it possible (when Deleting, inside a thrift Mutation) to loop through all the columns that need to be deleted find there type, 'validation_class' (regular or CounterColumnType) and delete them base on there type?
        Hide
        Jonathan Ellis added a comment -

        "Not worth breaking Thrift compatibility" means not in 1.0 either.

        Show
        Jonathan Ellis added a comment - "Not worth breaking Thrift compatibility" means not in 1.0 either.
        Hide
        Chris Burroughs added a comment -

        That's CQL in 0.8.1 for this ticket and a new one for Thrift api in 1.0?

        Show
        Chris Burroughs added a comment - That's CQL in 0.8.1 for this ticket and a new one for Thrift api in 1.0?
        Hide
        Jonathan Ellis added a comment -

        I'd be fine with saying it's only supported from CQL. It's not worth breaking Thrift compatibility over.

        Show
        Jonathan Ellis added a comment - I'd be fine with saying it's only supported from CQL. It's not worth breaking Thrift compatibility over.
        Hide
        Sylvain Lebresne added a comment -

        Turns out there is a tiny hiccup.
        For a Deletion (inside a thrift Mutation), the timestamp is required to be set if the CF is a regular one, but not if it is a counter CF. But more importantly, for counter CF, the timestamp should be a server generated timestamp.

        If we allow row to mix counters and regular columns, then when facing a Deletion for a full row, there is no way to accommodate those two requirements. It would kind of be a shame of not doing this because of Deletion, but I don't see a good way around this (other than changing the API, which would move that ticket to 1.0).

        Ideas ?

        Show
        Sylvain Lebresne added a comment - Turns out there is a tiny hiccup. For a Deletion (inside a thrift Mutation), the timestamp is required to be set if the CF is a regular one, but not if it is a counter CF. But more importantly, for counter CF, the timestamp should be a server generated timestamp. If we allow row to mix counters and regular columns, then when facing a Deletion for a full row, there is no way to accommodate those two requirements. It would kind of be a shame of not doing this because of Deletion, but I don't see a good way around this (other than changing the API, which would move that ticket to 1.0). Ideas ?
        Hide
        Ryan King added a comment -

        Ah, that makes more sense.

        Show
        Ryan King added a comment - Ah, that makes more sense.
        Hide
        Sylvain Lebresne added a comment -

        To be more specific, the idea is for instance to allow counter in a non-counter CF with something like

        column_metadata =   [
           {column_name: first, validation_class: UTF8Type},
           {column_name: last, validation_class: UTF8Type},
           {column_name: friends, validation_class: CounterColumnType}   ];
        

        In which case we know when we expect a counter and when we do not. Moreover the code already handle mixing counter and non counter mutations in a batch_mutate, so most of the handling of the different write path is already there. We will still have to "extract" the counter column for this so that it goes through the correct write path, but that can be done while we translate the thrift structures to our internal representations.

        Show
        Sylvain Lebresne added a comment - To be more specific, the idea is for instance to allow counter in a non-counter CF with something like column_metadata = [ {column_name: first, validation_class: UTF8Type}, {column_name: last, validation_class: UTF8Type}, {column_name: friends, validation_class: CounterColumnType} ]; In which case we know when we expect a counter and when we do not. Moreover the code already handle mixing counter and non counter mutations in a batch_mutate, so most of the handling of the different write path is already there. We will still have to "extract" the counter column for this so that it goes through the correct write path, but that can be done while we translate the thrift structures to our internal representations.
        Hide
        Jonathan Ellis added a comment -

        the proposal is to allow mixing counter/non-counter in the same CF (row), not the same column

        Show
        Jonathan Ellis added a comment - the proposal is to allow mixing counter/non-counter in the same CF (row), not the same column
        Hide
        Ryan King added a comment -

        I don't think this is feasible to do robustly. Several problems

        1. If a column is initially created as a counter, but a non-counter insert comes through what do we do? We can't give the inserter an error unless we introduce reads in the write path.
        2. The write path is somewhat different for the two kinds of columns. Counters don't really respect CLs the same way normal columns do.

        Show
        Ryan King added a comment - I don't think this is feasible to do robustly. Several problems 1. If a column is initially created as a counter, but a non-counter insert comes through what do we do? We can't give the inserter an error unless we introduce reads in the write path. 2. The write path is somewhat different for the two kinds of columns. Counters don't really respect CLs the same way normal columns do.

          People

          • Assignee:
            Unassigned
            Reporter:
            Dave Rav
          • Votes:
            4 Vote for this issue
            Watchers:
            13 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development