incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Replogle <david.replo...@steketeegreiner.com>
Subject Re: Sorting problem on supercolumns names using OPP on 0.6.2
Date Mon, 06 Dec 2010 18:44:30 GMT
+1

I'm doing this in my C++ client so contact me offlist if you need code

David
Sent from my iPhone

On Dec 6, 2010, at 1:33 PM, Tyler Hobbs <tyler@riptano.com> wrote:

> Also, thought I should mention:
> 
> When you make a std::string out of the char[], make sure to use the constructor with
the size_t parameter (size 8).
> 
> - Tyler
> 
> On Mon, Dec 6, 2010 at 12:29 PM, Tyler Hobbs <tyler@riptano.com> wrote:
> That should be "big-endian".
> 
> 
> On Mon, Dec 6, 2010 at 12:29 PM, Tyler Hobbs <tyler@riptano.com> wrote:
> How are you packing the longs into strings?  The large negative numbers point to that
being done incorrectly.
> 
> Bitshifting and putting each byte of the long into a char[8] then stringifying the char[]
is the best way to go.  Cassandra expects
> big-ending longs, as well.
> 
> - Tyler
> 
> 
> On Mon, Dec 6, 2010 at 11:55 AM, Guillermo Winkler <gwinkler@inconcertcc.com> wrote:
> I'm using thrift in C++ and inserting the results in a vector of pairs, so client-side-mangling
does not seem to be the problem.
> 
> Also I'm using a "test" column where I insert the same value I'm using as super column
name (in this case the same date converted to string) and when queried using cassandra cli
is unsorted too:
> 
> cassandra> get Events.EventsByUserDate ['guille']
> => (super_column=9088542550893002752,
>      (column=4342323443303834363833383437454339364433324530324538413039373736, value=2010-12-06
17:43:36.000, timestamp=1291657416526732))
> => (super_column=5990347482238812160,
>      (column=41414e4c6b54696d6532423656566e6869667a336f654b6147393d2d395a4e797441397a744f39686d3147392b406d61696c2e676d61696c2e636f6d,
value=2010-12-06 17:46:08.000, timestamp=1291657568569039))
> => (super_column=-3089190841516818432,
>      (column=3634343644353236463830303437363542454245354630343845393533373337, value=2010-12-06
17:44:47.000, timestamp=1291657487450738))
> => (super_column=-4026221038986592256,
>      (column=62303232396330372d636430612d343662332d623834382d393632366136323061376532,
value=2010-12-06 17:39:50.000, timestamp=1291657190117981))
> 
> 
> 
> 
> On Mon, Dec 6, 2010 at 3:02 PM, Tyler Hobbs <tyler@riptano.com> wrote:
> What client are you using?  Is it storing the results in a hash map or some other type
of
> non-order preserving dictionary?
> 
> - Tyler
> 
> 
> On Mon, Dec 6, 2010 at 10:11 AM, Guillermo Winkler <gwinkler@inconcertcc.com> wrote:
> Hi, I've the following schema defined:
> 
> EventsByUserDate : { 
> 					UserId : {
> 						epoch: { // SC
> 							IID, 
> 							IID,
> 							IID,
> 							IID
> 						},
> 						// and the other events in time
> 						epoch: {
> 							IID,
> 							IID,
> 							IID
> 						}
> 					}
> }
> <ColumnFamily ColumnType="Super" CompareWith="LongType" CompareSubcolumnsWith="BytesType"
Name="EventsByUserDate "/>
> 
> Where I'm expecting to store all the event ids for a user ordered by date (it's seconds
since epoch as long long), I'm using OrdingPreservingPartitioner.
> 
> But a call to:
> 
> GetSuperRangeSlices("EventsByUserDate ",  --column family
> 				"",  --supercolumn
> 				userId, --startkey
> 				userId, --endkey
> 				 { 
> 				   column_names = {},
> 				   slice_range = { 
> 				     start = "", 
> 				     finish = "", 
> 				     reversed = true, 
>                                      count = 20}							},
>                                 1 --total keys
> 		               ) 
> 
> Is not sorting correctly by supercolumn (the supercolumn names come out unsorted), this
is a sample output for the pervious query using thrift directly:
> 
> SC 1291648883
> SC 1291588465
> SC 1291588453
> SC 1291586385
> SC 1291587408
> SC 1291588174
> SC 1291585331
> SC 1291587116
> SC 1291651116
> SC 1291586332
> SC 1291588548
> SC 1291588036
> SC 1291648703
> SC 1291583651
> SC 1291583650
> SC 1291583649
> SC 1291583648
> SC 1291583647
> SC 1291583646
> SC 1291587485
> 
> 
> Anything I'm missing regarding sorting schemes? 
> 
> Thanks,
> Guille
> 
> 
> 
> 
> 
> 

Mime
View raw message