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 >
