Right, we don't currently support scanning rows in reverse order, but that is only because nobody has wanted it badly enough to code it. :)
On Tue, Feb 2, 2010 at 6:06 PM, Erik Holstad <erikhols...@gmail.com> wrote: > Hey Nate! > What I wanted to do with the get_range_slice was to receive the keys in the > inverted order, so that I could so offset limit queries on key ranges in > reverse > order. Like you said, this can be done for both columns and super columns > with > help of the SliceRange, but not on keys afaik, but maybe there is a way? > > Thanks Erik > > > On Tue, Feb 2, 2010 at 3:55 PM, Nathan McCall <n...@vervewireless.com> > wrote: >> >> Erik, >> You can do an inverse with 'reversed=true' in SliceRange as part of >> the SlicePredicate for both get_slice or get_range_slice. I have not >> tried reverse=true on SuperColumn results, but I dont think there is >> any difference there - what can't be changed is how things are ordered >> but direction can go either way (If I am wrong on this, somebody >> please correct me). >> >> http://issues.apache.org/jira/browse/CASSANDRA-598 has not been on my >> radar as I dont have anything reporting-ish like you describe with >> SuperColumns (yet). I will defer to more experienced folks with this. >> >> Regards, >> -Nate >> >> >> On Tue, Feb 2, 2010 at 3:02 PM, Erik Holstad <erikhols...@gmail.com> >> wrote: >> > @Nathan >> > So what I'm planning to do is to store multiple sort orders for the same >> > data, where they all use the >> > same data table just fetches it in different orders, so to say. I want >> > to be >> > able to rad the different sort >> > orders from the front and from the back to get both regular and reverse >> > sort >> > order. >> > >> > With your approach using super columns you would need to replicate all >> > data, >> > right? >> > >> > And if I understand http://issues.apache.org/jira/browse/CASSANDRA-598 >> > correctly you would need to >> > read the whole thing before you can limit the results handed back to >> > you. >> > >> > In regards to the two calls get_slice and get_range_slice, the way I >> > understand it is that you hand >> > the second one an optional start and stop key plus a limit, to get a >> > range >> > of keys/rows. I was planning >> > to use this call together with the OPP, but are thinking about not using >> > it >> > since there is no way to do >> > an inverse scan, right? >> > >> > Thanks a lot >> > Erik >> > >> > >> > On Tue, Feb 2, 2010 at 2:39 PM, Jesse McConnell >> > <jesse.mcconn...@gmail.com> >> > wrote: >> >> >> >> infinite is a bit of a bold claim.... >> >> >> >> by my understanding you are bound by the memory of the jvm as all of >> >> the content of a key/row currently needs to fit in memory for >> >> compaction, which includes columns and supercolumns for given key/row. >> >> >> >> if you are going to run into those scenarios then some sort of >> >> sharding on the keys is required, afaict >> >> >> >> cheers, >> >> jesse >> >> >> >> -- >> >> jesse mcconnell >> >> jesse.mcconn...@gmail.com >> >> >> >> >> >> >> >> On Tue, Feb 2, 2010 at 16:30, Nathan McCall <n...@vervewireless.com> >> >> wrote: >> >> > Erik, >> >> > Sure, you could and depending on the workload, that might be quite >> >> > efficient for small pieces of data. However, this also sounds like >> >> > something that might be better addressed with the addition of a >> >> > SuperColumn on "Sorts" and getting rid of "Data" altogether: >> >> > >> >> > Sorts : { >> >> > sort_row_1 : { >> >> > sortKey1 : { col1:val1, col2:val2 }, >> >> > sortKey2 : { col1:val3, col2:val4 } >> >> > } >> >> > } >> >> > >> >> > You can have an infinite number of SuperColumns for a key, but make >> >> > sure you understand get_slice vs. get_range_slice before you commit >> >> > to >> >> > a design. Hopefully I understood your example correctly, if not, do >> >> > you have anything more concrete? >> >> > >> >> > Cheers, >> >> > -Nate >> >> > >> >> > >> >> > On Tue, Feb 2, 2010 at 12:00 PM, Erik Holstad <erikhols...@gmail.com> >> >> > wrote: >> >> >> Thanks Nate for the example. >> >> >> >> >> >> I was thinking more a long the lines of something like: >> >> >> >> >> >> If you have a family >> >> >> >> >> >> Data : { >> >> >> row1 : { >> >> >> col1:val1, >> >> >> row2 : { >> >> >> col1:val2, >> >> >> ... >> >> >> } >> >> >> } >> >> >> >> >> >> >> >> >> Using >> >> >> Sorts : { >> >> >> sort_row : { >> >> >> sortKey1_datarow1: [], >> >> >> sortKey2_datarow2: [] >> >> >> } >> >> >> } >> >> >> >> >> >> Instead of >> >> >> Sorts : { >> >> >> sort_row : { >> >> >> sortKey1: datarow1, >> >> >> sortKey2: datarow2 >> >> >> } >> >> >> } >> >> >> >> >> >> If that makes any sense? >> >> >> >> >> >> -- >> >> >> Regards Erik >> >> >> >> >> > >> > >> > >> > >> > -- >> > Regards Erik >> > > > > > -- > Regards Erik >
