hadoop-common-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Lucene-hadoop Wiki] Trivial Update of "Hbase/HbaseRest" by stack
Date Sun, 18 Nov 2007 23:59:33 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Lucene-hadoop Wiki" for change notification.

The following page has been changed by stack:
http://wiki.apache.org/lucene-hadoop/Hbase/HbaseRest

------------------------------------------------------------------------------
              Multipart/related:  The client is expecting raw binary data, but organized into
a 
                                  multipart response. The client must be prepared to parse
the 
                                  column values out of the data.
+ 
-     Options: 
+     Options:
+ 
          columns: A semicolon-delimited list of column names. If omitted, the result will
contain all columns in the row.
  
  ~-''St.Ack comment 11/17/2007: Only one column allowed in hbase currently.-~
@@ -96, +98 @@

      Headers:
          Content-type:
              application/xml:    The client is sending one or more columns of data in an
XML entity.
+ 
              Multipart/related:  The client is sending multiple columns of data encoded with
boundaries.
              
      Options:
+ 
          columns: A semicolon-delimited list of column names. This attribute is ignored when
the Content-type is application/xml.
      
      Returns:
@@ -111, +115 @@

  ~-''Bryan comment: While we certainly could use headers, I'd prefer not to. Headers seem
like an ugly way to say what you're sending. In REST, you're supposed to specify '''what'''
you're acting on in the URI, not headers, and which columns to save to qualifies to me. It
may turn out to be an implementation question, but we'll see. ''-~
  
  
- ~-''St.Ack comment 11/15/2007: I agree -~ 
+ ~-''St.Ack comment 11/15/2007: I agree -~
+ 
+ ~-''St.Ack comment 11/18/2007: If the get on a row is full -- i.e. return all cells in a
row -- there is no way for response to say what the column name for the cell is when doing
MIME other than put it in the header (Content-Description header?).  To be symmetric, maybe
client posting data should put column name in same place? I could do implementation so it
works with both.-~ 
  
      
  '''DELETE /[table_name]/row/[row_key]/'''
@@ -121, +127 @@

      Delete the specified columns from the row. If there are no columns specified, then it
will delete ALL columns. Optionally, specify a timestamp.
      
      Options:
+ 
          columns: A semicolon-delimited list of column names. If omitted, the result will
delete all columns in the row.
      
      Returns:
@@ -131, +138 @@

  
  '''POST/PUT /[table_name]/scanner'''
      Request that a scanner be created with the specified options. Returns a scanner ID that
can be used to iterate over the results of the scanner.
+ 
      Options: 
+ 
          columns: A semicolon-delimited list of column names. If omitted, each result will
contain all columns in the row.
          
          start_key, end_key: Starting and ending keys that enclose the region that should
be scanned.
+         
+         timestamp: Timestamp at which to start the scanner.
+ 
  
      Returns:
          HTTP 201 (Created) with a Location header that references the scanner URI. Example:
          /first_table/scanner/1234348890231890
+ 
+ ~-''St.Ack comment 11/18/2007: I added timestamp parameter. Should start_key, end_key, OR
timestamp be on the URL path to sync. with how they are specified GET'ing, etc?-~
+ 
          
  '''GET /[table_name]/scanner/[scanner_id]/current'''
      Get the row and columns for the current item in the scanner without advancing the scanner.

@@ -183, +198 @@

  
  ~- Bryan comment: What I mean is that instead of supporting two separate verbs to two different
URIs (/current and /next) there would be only one URI with two verbs. Additionally, after
some more thought, I think DELETE would be better because it implies that something is being
consumed or deleted, as opposed to POST/PUT which sort of imply something new is being created.
Again, though, I think it is a bit of hair splitting, seeing as how the HTTP spec is going
to have to be bent a little to work right for this particular request anyways (DELETE or POST/PUT
shouldn't usually return an entity-body, and we will want it to so that we don't have to make
two separate requests, one for getting the current and another for advancing it). -~
  
- ~-''St.Ack comment 11/18/2007: Trying to implement, the 'current' tail on a resource URI
doesn't add any value GET'ing; what else but the 'current' record would you be GETing. A GET
on a URI that ends in a scannerid is enough to figure whats wanted.  If this is allowed, given
that below a delete on a URI that ends in a scannerid closes the scanner, I would suggest
that a PUT/POST on an URI that ends in a scannerid is the way to advance it (returning current
value).-~
+ ~-''St.Ack comment 11/18/2007: Trying to implement, the 'current' tail on a resource URI
doesn't add any value GET'ing; what else but the 'current' record would you be GETing. A GET
on a URI that ends in a scannerid is enough to figure whats wanted.  If this is allowed, given
that below a delete on a URI that ends in a scannerid closes the scanner, I would suggest
that a PUT/POST on an URI that ends in a scannerid is the way to advance it (returns the 'next'
value -- you have to call 'next' on scanner to get first value).-~
  
  
  '''DELETE /[table_name]/scanner/[scanner_id]'''

Mime
View raw message