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 |
din...@piedpiper.com
-8838453544589358145 | Engineering | Gilfoyle |
thedark...@piedpiper.com
-8838453544589358145 | Engineering | Richard |
rich...@piedpiper.com
-4463195796437695053 | Marketing | Erlich |
erl...@piedpiper.com
-3086103490616810985 | Finance/HR | Jared |
don...@piedpiper.com
(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 <soheil.i...@gmail.com>
wrote:
> To the point, Thanks!
>
> On Sun, Jul 15, 2018 at 4:31 PM, shalom sagges <shalomsag...@gmail.com>
> 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 <
>> soheil.i...@gmail.com> 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?
>>>
>>
>>
>
