It's impossible to implement offset either performantly or safely in a distributed log-structured merge system that supports deletes. The original API punted on all three of those. 0.4 doesn't. See https://issues.apache.org/jira/browse/CASSANDRA-261 for a discussion of performance (we decided that that alone wasn't enough to keep the feature out) and https://issues.apache.org/jira/browse/CASSANDRA-286 for details on the safety problems (which broke the camel's back).
It sucks when you have to take functionality *out* but that was the only sane option here. IMO, compared to manual sharding a relational DB (in which case you still can't just do a simple offset when you cross partitions!), pulling out NxM results where N is the number of pages and M is the number of results per page isn't that big a deal. Or just throw some ajax magic in to make the ugly next button go away, like the slashdot front page does with the scrollbar. :) -Jonathan On Wed, Aug 12, 2009 at 8:22 PM, Tangram Liu<lang...@gmail.com> wrote: > Thanks for your reply. But I really don't want to use a ugly "next" button > or just only capable return 100 results in 10 pages. I just can't understand > why cassandra's new api remove this useful feature and replace with the new > one. > > Pagination is an extremely common use case scenario in web app programming. > almost every web app need “one to many” data model. when the “many” part is > too many to fit in one page, paginate is the best way to resolve it. in most > case, we don't need query or sort the result in a complicated way. we just > need save them in time or alphabetic order, view first 20 records and > provide an paginator at the bottom for the others. this is one reason > why enhanced > key-value(pure k-v db is too sample and relational db is too > comprehensive, we need something between them) database coming popular > recent year. > > i think one of the most basic function the enhanced k-v db should > provide is the capability to define 'one to many' relationship(many to > many relationship can build with two 'one to many' list). > > the old api can build 'one > to many' list in a very sample way - just use 'one' part as key, and > 'many' part as a list of columns which sort in time or alphabetic > order and paginate them with start and count parameters. with new api > i just can't figure out how to build it. > > could anyone here tell me why new api abandon the old design? how to > build 'one to many' relationship in a effective way with new api? what > data model should i use? thank? > > 2009/8/13 Jonathan Ellis <jbel...@gmail.com> > >> The easy way is to just show one page of results and have a Next >> button that uses start=last one from current page. >> >> The slightly harder way if you want to show say 10 links to the next >> 10 pages is, you have to select 10 pages worth of data and manually >> offset into that. >> >> -Jonathan >> >> On Tue, Aug 11, 2009 at 10:37 PM, Tangram Liu<lang...@gmail.com> wrote: >> > Hi, there! I'm new to cassandra. and I think it fascinating. >> > >> > I got a question here: >> > >> > image a simple blog host app base on cassandra with the following data >> > model: >> > >> > <Keyspaces> >> > <Keyspace Name="MultiBlog"> >> > <ColumnFamily CompareWith="TimeUUIDType" Name="Blogs"> >> > </Keyspace> >> > </Keyspaces> >> > >> > for each new blog article, insert with blog name as the key, article >> title >> > as the column name and article content as value. >> > >> > here is the question: how can i build a blog paginator with new api? >> > >> > with old api, i can simple use get_slice to get what i want(start=page >> > offset, count= row per page). but new api, however, change the start >> > parameter type from int to string. how can i build a paginate function >> with >> > new api? >> >
