Basically I am trying different queries with your approach. One such query is like
Select * from mycf where condition on partition key order by ck1 asc, ck2 desc where ck1 and ck2 are clustering keys in that order. Here how do we achieve pagination support? Thanks Ajay On Feb 11, 2015 11:16 PM, "Ajay" <ajay.ga...@gmail.com> wrote: > > Hi Eric, > > Thanks for your reply. > > I am using Cassandra 2.0.11 and in that I cannot append condition like > last clustering key column > value of the last row in the previous batch. > It fails Preceding column is either not restricted or by a non-EQ relation. > It means I need to specify equal condition for all preceding clustering > key columns. With this I cannot get the pagination correct. > > Thanks > Ajay > > I can't believe that everyone read & process all rows at once (without > pagination). > > Probably not too many people try to read all rows in a table as a single > rolling operation with a standard client driver. But those who do would > use token() to keep track of where they are and be able to resume with that > as well. > > But it sounds like you're talking about paginating a subset of data - > larger than you want to process as a unit, but prefiltered by some other > criteria which prevents you from being able to rely on token(). For this > there is no general purpose solution, but it typically involves you > maintaining your own paging state, typically keeping track of the last > partitioning and clustering key seen, and using that to construct your next > query. > > For example, we have client queries which can span several partitioning > keys. We make sure that the List of partition keys generated by a given > client query List(Pq) is deterministic, then our paging state is the > index offset of the final Pq in the response, plus the value of the final > clustering column. A query coming in with a paging state attached to it > starts the next set of queries from the provided Pq offset where > clusteringKey > the provided value. > > So if you can just track partition key offset (if spanning multiple > partitions), and clustering key offset, you can construct your next query > from those instead. > > On Tue, Feb 10, 2015 at 6:58 PM, Ajay <ajay.ga...@gmail.com> wrote: > >> Thanks Alex. >> >> But is there any workaround possible?. I can't believe that everyone read >> & process all rows at once (without pagination). >> >> Thanks >> Ajay >> On Feb 10, 2015 11:46 PM, "Alex Popescu" <al...@datastax.com> wrote: >> >>> >>> On Tue, Feb 10, 2015 at 4:59 AM, Ajay <ajay.ga...@gmail.com> wrote: >>> >>>> 1) Java driver implicitly support Pagination in the ResultSet (using >>>> Iterator) which can be controlled through FetchSize. But it is limited in a >>>> way that we cannot skip or go previous. The FetchState is not exposed. >>> >>> >>> Cassandra doesn't support skipping so this is not really a limitation of >>> the driver. >>> >>> >>> -- >>> >>> [:>-a) >>> >>> Alex Popescu >>> Sen. Product Manager @ DataStax >>> @al3xandru >>> >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to java-driver-user+unsubscr...@lists.datastax.com. >>> >> >
