It also helps to think about it with the token values of the partition key
in place. Assume I have a table "users_by_dept" keyed like this: PRIMARY
KEY ((department),username).
Querying that table with the token function on the partition key looks like
this:
SELECT token(department),department,username,email FROM users_by_dept ;
system.token(department) | department | username | email
--------------------------+-------------+----------+--------------------------
-8838453544589358145 | Engineering | Dinesh |
[email protected]
-8838453544589358145 | Engineering | Gilfoyle |
[email protected]
-8838453544589358145 | Engineering | Richard |
[email protected]
-4463195796437695053 | Marketing | Erlich |
[email protected]
-3086103490616810985 | Finance/HR | Jared |
[email protected]
(5 rows)
As you can see, department doesn't appear to be in any discernable order
until you apply the token function to it.
Aaron
On Sun, Jul 15, 2018 at 8:05 AM, Soheil Pourbafrani <[email protected]>
wrote:
> To the point, Thanks!
>
> On Sun, Jul 15, 2018 at 4:31 PM, shalom sagges <[email protected]>
> wrote:
>
>> The clustering column is ordered per partition key.
>>
>> So if for example I create the following table:
>> create table desc_test (
>> id text,
>> name text,
>> PRIMARY KEY (id,name)
>> ) WITH CLUSTERING ORDER BY (name DESC );
>>
>>
>> I insert a few rows:
>>
>> insert into desc_test (id , name ) VALUES ( 'abc', 'abc');
>> insert into desc_test (id , name ) VALUES ( 'abc', 'bcd');
>> insert into desc_test (id , name ) VALUES ( 'abc', 'aaa');
>> insert into desc_test (id , name ) VALUES ( 'fgh', 'aaa');
>> insert into desc_test (id , name ) VALUES ( 'fgh', 'bcd');
>> insert into desc_test (id , name ) VALUES ( 'fgh', 'abc');
>>
>>
>> And then read:
>> select * from desc_test;
>>
>> id | name
>> -----+------
>> fgh | bcd
>> fgh | abc
>> fgh | aaa
>> abc | bcd
>> abc | abc
>> abc | aaa
>>
>> (6 rows)
>>
>>
>> You can see that the data is properly ordered in descending mode, BUT
>> *for each partition key. *
>> So in order to achieve what you want, you will have to add the relevant
>> partition key for each select query.
>>
>> Hope this helps
>>
>>
>> On Sun, Jul 15, 2018 at 2:16 PM, Soheil Pourbafrani <
>> [email protected]> wrote:
>>
>>> I created table using the command:
>>> CREATE TABLE correlated_data (
>>> processing_timestamp bigint,
>>> generating_timestamp bigint,
>>> data text,
>>> PRIMARY KEY (processing_timestamp, generating_timestamp)
>>> ) WITH CLUSTERING ORDER BY (generating_timestamp DESC);
>>>
>>>
>>> When I get data using the command :
>>> SELECT * FROM correlated_data LIMIT 1 ;
>>>
>>> I expect it return the row with the biggest field "generating_timestamp",
>>> but I got the same row every time I run the query, while row with bigger "
>>> generating_timestamp" exists. What's the problem?
>>>
>>
>>
>
