cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <>
Subject Re: New thrift api question.
Date Thu, 13 Aug 2009 01:28:36 GMT
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 for a discussion
of performance (we decided that that alone wasn't enough to keep the
feature out) and
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. :)


On Wed, Aug 12, 2009 at 8:22 PM, Tangram Liu<> 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 <>
>> 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<> 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?

View raw message