Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of jbellis@gmail.com designates
 209.85.219.212 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=Fq0bzR3g13J9AjFrwfP8faV4xc5kw3b2yQe1Rv16uUxhnH4/TslZgj+ULOT9KiDNnP
         Ed8MbMYMZH67N26pFOqrA6u77R57Xr5a/Yt/gnyrHieK3Ly6WhQnCeUAskHTDqLV57qC
         YUwz2KVSToo9yD+XkeIyRU75dSG76HtH8D7OI=
MIME-Version: 1.0
In-Reply-To: <3bb1d9610908121822n5a3dbd8csfc43f1d3e9758de7@mail.gmail.com>
References: <3bb1d9610908112037v17b852ev9dc0b8798969061a@mail.gmail.com>
	 <e06563880908120926h353070fds2ace8831c07d012f@mail.gmail.com>
	 <3bb1d9610908121822n5a3dbd8csfc43f1d3e9758de7@mail.gmail.com>
Date: Wed, 12 Aug 2009 20:28:36 -0500
Message-ID: <e06563880908121828w7a3463eds9fb5ab01f8c77f1@mail.gmail.com>
Subject: Re: New thrift api question.
From: Jonathan Ellis <jbellis@gmail.com>
To: cassandra-user@incubator.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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<langram@gmail.com> wrote:
> Thanks for your reply. But I really don't want to use a ugly "next" butto=
n
> or just only capable return 100 results in 10 pages. I just can't underst=
and
> why cassandra's new api remove this useful feature and replace with the n=
ew
> one.
>
> Pagination is an extremely common use case scenario in web app programmin=
g.
> almost every web app need =93one to many=94 data model. when the =93many=
=94 part is
> too many to fit in one page, paginate is the best way to resolve it. in m=
ost
> case, we don't need query or sort the result in a complicated way. we jus=
t
> 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 <jbellis@gmail.com>
>
>> The easy way is to just show one page of results and have a Next
>> button that uses start=3Dlast 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<langram@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>
>> > =A0 =A0 <Keyspace Name=3D"MultiBlog">
>> > =A0 =A0 =A0 =A0 <ColumnFamily CompareWith=3D"TimeUUIDType" Name=3D"Blo=
gs">
>> > =A0 =A0 </Keyspace>
>> > =A0</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=3Dpa=
ge
>> > offset, count=3D 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?
>>
>