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

          stack made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          stack made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 0.19.0 [ 12313364 ]
          Fix Version/s 0.20.0 [ 12313474 ]
          Resolution Fixed [ 1 ]
          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.
          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
          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).
          stack made changes -
          Fix Version/s 0.19.0 [ 12313364 ]
          Fix Version/s 0.20.0 [ 12313474 ]
          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
          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?
          Jim Kellerman made changes -
          Assignee Jim Kellerman [ jimk ] Doğacan Güney [ dogacan ]
          Jim Kellerman made changes -
          Fix Version/s 0.19.0 [ 12313364 ]
          Jim Kellerman made changes -
          Assignee Jim Kellerman [ jimk ]
          Jim Kellerman made changes -
          Issue Type New Feature [ 2 ] Sub-task [ 7 ]
          Parent HBASE-847 [ 12403181 ]
          Jim Kellerman made changes -
          Link This issue is part of HBASE-33 [ HBASE-33 ]
          Jim Kellerman made changes -
          Link This issue is blocked by HBASE-733 [ HBASE-733 ]
          Jim Kellerman made changes -
          Link This issue is part of HBASE-33 [ HBASE-33 ]
          Bryan Duxbury made changes -
          Component/s client [ 12312131 ]
          Owen O'Malley made changes -
          Field Original Value New Value
          Project Hadoop Core [ 12310240 ] Hadoop HBase [ 12310753 ]
          Key HADOOP-2386 HBASE-44
          Component/s contrib/hbase [ 12311752 ]
          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.
          Bryan Duxbury created issue -

            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