I put a sample patch at HBASE-8284, I will let someone from the HBase
committee take a look before moving any further with it...
On Thu, Apr 4, 2013 at 12:13 PM, Nick Dimiduk <[EMAIL PROTECTED]> wrote:
> Wouldn't offset be a family:qualifier instead of a String?
> Please consider adding two interfaces: a version which exposes the state
> externally (as you've described) and another that encapsulates the state
> handling on the user's behalf. The former is useful for exposing over
> stateless protocols like REST while the latter is more convenient for other
> On Thu, Apr 4, 2013 at 10:31 AM, Varun Sharma <[EMAIL PROTECTED]> wrote:
> > Hi,
> > I am thinking of adding a string offset to ColumnPaginationFilter. There
> > are two reasons:
> > 1) For deep pagination, you can seek using SEEK_NEXT_USING_HINT.
> > 2) For correctness reasons, this approach is better if the list of
> > is mutation. Lets say you get 1st 50 columns using the current approach.
> > the mean time some columns are inserted amongst the 1st 50 columns. Now
> > request the 2nd set of 50 columns. Chances are that you will have
> > duplicates amongst the 2 sets (1st 50 and 2nd 50). If instead you used
> > last column of the 1st 50 as a string offset for getting the 2nd set of
> > columns, the chances of getting dups is significantly lower.
> > This becomes important for user facing interactive applications.
> > Particularly where consistency etc. are not as important since those are
> > best effort services. But showing duplicates across pages is pretty bad.
> > Please let me know if this makes sense and is feasible. Basically, I
> > like a string offset passed to ColumnPaginationFilter as an alternative
> > constructor. If the string offset is supplied, then, I would like to seek
> > to either the column supplied or if the column is deleted, seek to the
> > column just greater than the supplied column.
> > Thanks
> > Varun