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: > +1 > > 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 > applications. > > -n > > 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 > columns > > is mutation. Lets say you get 1st 50 columns using the current approach. > In > > the mean time some columns are inserted amongst the 1st 50 columns. Now > you > > 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 > the > > 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 > would > > 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 > > >
