HBase
  1. HBase
  2. HBASE-847 new API: HTable.getRow with numVersion specified
  3. HBASE-44

[hbase] Method to get a number of timestamped versions of a row all at once

    Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.19.0
    • Component/s: Client
    • Labels:
      None

      Description

      If you have rows that are densely populated (most versions have all the columns) and heavily versioned, and if you are doing things like checking difference between the versions, it would be really handy to be able to get all of the versions and data at once. This method would let you do that.

      Map<long, Map<Text, byte[]>> getRowTimestampsWithColumns(Text row);
      Map<long, Map<Text, byte[]>> getRowTimestampsWithColumns(Text row, Text[] columns);
      Map<long, Map<Text, byte[]>> getRowTimestampsWithColumns(Text row, Text[] columns, long timestamp);
      Map<long, Map<Text, byte[]>> getRowTimestampsWithColumns(Text row, Text[] columns, long timestamp, int numVersions);
      

        Issue Links

          Activity

          Hide
          Thomas Garner added a comment -

          +1 vote for this feature request. The timestamp should be promoted to a first class citizen. For any timestamped data, reading it back without knowing the timestamp at which it was written is undesirable. I would imagine it worthwhile to have scanners return access to the timestamp as well.

          Show
          Thomas Garner added a comment - +1 vote for this feature request. The timestamp should be promoted to a first class citizen. For any timestamped data, reading it back without knowing the timestamp at which it was written is undesirable. I would imagine it worthwhile to have scanners return access to the timestamp as well.
          Hide
          stack added a comment -

          Doğacan, OK if we move this out of 0.19.0 and do it in 0.20.0 timeframe instead?

          Show
          stack added a comment - Doğacan, OK if we move this out of 0.19.0 and do it in 0.20.0 timeframe instead?
          Hide
          stack added a comment -

          Moving to 0.20.0 with Doğacan Güney's permission over in hbase-847

          Show
          stack added a comment - Moving to 0.20.0 with Doğacan Güney's permission over in hbase-847
          Hide
          Doğacan Güney added a comment -

          Stack, it seems I didn't understand what you meant As I indicated in an earlier comment on HBASE-847, I think patch there also fixes this issue. I mean, it adds a new method:

          public RowResult getRow(byte[] row, byte[][] columns, long timestamp, int numVersions)
          

          which does what this issue asks, right?

          This is also true for HBASE-857. I think HBASE-31 is also covered, but you may disagree (since you get multiple versions of data+timestamps, but can not just get multiple versions of timestamps).

          Show
          Doğacan Güney added a comment - Stack, it seems I didn't understand what you meant As I indicated in an earlier comment on HBASE-847 , I think patch there also fixes this issue. I mean, it adds a new method: public RowResult getRow( byte [] row, byte [][] columns, long timestamp, int numVersions) which does what this issue asks, right? This is also true for HBASE-857 . I think HBASE-31 is also covered, but you may disagree (since you get multiple versions of data+timestamps, but can not just get multiple versions of timestamps).
          Hide
          Jim Kellerman added a comment -

          Doğacan,

          I agree that this satisfies HBASE-31. Even though we drag over cell contents,
          it is highly likely (at least in the applications I've seen) that the client
          application will use the cell contents more often than not.

          I think that the best reason for this issue to be pushed to 0.20.0 is that it
          will be a whole lot easier with the new api (HBASE-880) in place.

          Show
          Jim Kellerman added a comment - Doğacan, I agree that this satisfies HBASE-31 . Even though we drag over cell contents, it is highly likely (at least in the applications I've seen) that the client application will use the cell contents more often than not. I think that the best reason for this issue to be pushed to 0.20.0 is that it will be a whole lot easier with the new api ( HBASE-880 ) in place.
          Hide
          stack added a comment -

          Should have read the issue closer, sorry, yes, you are right Doğacan, hbase-847 resolves this issue.

          Will leave hbase-31 open since its explicit request for timestamps only not timestamps+data. I don't know why anyone would want that but maybe someone will. Its priority is already trivial.

          Show
          stack added a comment - Should have read the issue closer, sorry, yes, you are right Doğacan, hbase-847 resolves this issue. Will leave hbase-31 open since its explicit request for timestamps only not timestamps+data. I don't know why anyone would want that but maybe someone will. Its priority is already trivial.

            People

            • Assignee:
              Doğacan Güney
              Reporter:
              Bryan Duxbury
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development