Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.
The "Cassandra2474" page has been changed by JonathanEllis: http://wiki.apache.org/cassandra/Cassandra2474?action=diff&rev1=6&rev2=7 To address these problems, Cassandra added the CompositeType, which encodes a multi-value column name into a single column -- essentially the column name becomes a Tuple, for those with a background in Python. I will use Python tuple representation (x, y, z) to denote a composite column with components x, y, and z. - Composite columns are flexible enough that there are multiple ways to encode the same data. The most natural ways to encode the above timeline data are, first, an encoding where each object becomes a single column: + Composite columns are flexible enough that there are multiple ways to encode the same data. The most natural ways to encode the above timeline data are, first, an encoding where each object becomes a single column, with an empty value: ||tjefferson||(1763, 'Democracy will soon degenerate into an anarchy', 'jadams')||(1790, 'To be prepared for war is one of the most effectual means of preserving peace', 'gwashington')||(1818, 'Revolution was effected before the war commenced', 'jadams')|| + || ||[empty] ||[empty] ||[empty] || ||bfranklin ||(1781, 'Every government degenerates when trusted to the rulers of the people alone', 'tjefferson')|||||| + || ||[empty] |||||| - Note that a CompositeType definition includes type information -- (int, utf8, utf8) here -- but there is no column name information; this is governed purely by application convention. + (One could arbitrarily pick any column whose sort order is not important to be the column "value" instead, but I think it's more straightforward to treat things uniformly.) The main drawback to this representation is that like row keys, column names are necessarily immutable in Cassandra. So there is no way to update an object using this representation other than by deleting the old and adding the new. More subtly, this exposes us to some of the drawbacks of a pure key/value approach that normal Cassandra columns avoid: if one client updates field X in a result, while another client updates field Y, there will be no race when X and Y are distinct columns. But if these fields are stored as part of the same composite column then there is a race.
