hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phabricator (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5515) Add a processRow API that supports atomic multiple reads and writes on a row
Date Thu, 08 Mar 2012 02:34:59 GMT

    [ https://issues.apache.org/jira/browse/HBASE-5515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224951#comment-13224951

Phabricator commented on HBASE-5515:

jyates has commented on the revision "HBASE-5515 [jira] Add a processRow API that supports
atomic multiple reads and writes on a row".

  Still seems a bit bloated. I don't know what we really get from having the RowProcessor
_not_ be an endpoint in itself. A lot of the work here could be handled by just having an
abstract class that implements CoprocessorEndpoint and is subclasses by actual RowProcessor
implementations. This would also help keep the API more condensed. More thoughts inline on
how that would work.

  Otherwise, seems solid.

  src/main/java/org/apache/hadoop/hbase/coprocessor/ProcessRowEndpoint.java:34 This whole
process seems a bit roundabout. You make an endpoint that then takes the writable which immediately
then just calls the hregion to process that processor.... have to agree with Lars that the
endpoint should in fact just be the rowProcesssor - you would have the FriendsOfFriendsProcessor
just be a coprocessor that you turn on for your table.
  src/main/java/org/apache/hadoop/hbase/coprocessor/ProcessRowEndpoint.java:52 If you wanted
to make it easier for people to implement their own multi-action processing, then (going back
to my comment above) you can make the RowProcessorEnpoint just have an abstract method that
people use to implement their own processing.

  This abstract method would actually be called inside of the 'process' method that would
take care of getting the row lock, etc and leaving just the processing for the actual implementation
(which could return an iterable) and then push them back to the back.

  Some work would be involved in this approach, but it would be easily extractable into the
stuff from HBASE-5529
  src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java:4303 This seems like a lot
of copying from other parts in the code - maybe it can be abstracted out? This might be something
for the next patch for the MultiRowProcessor stuff


> Add a processRow API that supports atomic multiple reads and writes on a row
> ----------------------------------------------------------------------------
>                 Key: HBASE-5515
>                 URL: https://issues.apache.org/jira/browse/HBASE-5515
>             Project: HBase
>          Issue Type: New Feature
>            Reporter: Scott Chen
>            Assignee: Scott Chen
>         Attachments: HBASE-5515.D2067.1.patch, HBASE-5515.D2067.10.patch, HBASE-5515.D2067.11.patch,
HBASE-5515.D2067.12.patch, HBASE-5515.D2067.13.patch, HBASE-5515.D2067.14.patch, HBASE-5515.D2067.15.patch,
HBASE-5515.D2067.16.patch, HBASE-5515.D2067.17.patch, HBASE-5515.D2067.18.patch, HBASE-5515.D2067.19.patch,
HBASE-5515.D2067.2.patch, HBASE-5515.D2067.3.patch, HBASE-5515.D2067.4.patch, HBASE-5515.D2067.5.patch,
HBASE-5515.D2067.6.patch, HBASE-5515.D2067.7.patch, HBASE-5515.D2067.8.patch, HBASE-5515.D2067.9.patch
> We have modified HRegion.java internally to do some atomic row processing. It will be
nice to have a plugable API for this.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message